Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> GIT




On 6/5/13 8:44 AM, Keith Turner wrote:
> On Tue, Jun 4, 2013 at 10:49 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>
>>
>> On 06/04/2013 10:26 PM, Benson Margulies wrote:
>>
>>> 1.4.4 has been released. The first person finds some changes that should
>>>> be
>>>> placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>>>> created from the 1.4.4 tag.
>>>>
>>> What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
>>> 1.4.x? On other projects, there's an assumption of one branch per
>>> maintained minor version, with point releases as tags along they way.
>>> How is your more complex? scheme advantageous?
>>>
>> Much of this discussion is entirely based on the fact that my opinions
>> were solicited while the majority of people tended not to agree with how I
>> would prefer to manage branches.
>>
>> As such, I've stopped arguing my points as, and will attempt to be
>> detached.  Having been part of transition a decent-sized "subversion" team
>> to git, which typically tries to manage with 2+ concurrent releases, I've
>> developed my own opinions on how to manage this. Most of it stems from lack
>> of moderation on where changes should be made in such an environment and
>> that history is easily mucked up and when changes are placed in
>> inappropriate places. If it seems completely absurd to even have this
>> discussion (I don't fault you in the slightest -- I'm 99% there myself),
>> I'm actively working a write-up to track concrete decisions.
>>
>
> Can you give more detail about "history is easily mucked up"?  I am curious
> what constitutes a mucked up history and what sequence of steps lead to
> this?
>
http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html
>
>>
>> As far as a minor-release branch name, I really just don't care. It's a
>> name. My opinion is to tie it to something specific and meaningful. I do
>> not find 1.4.x nomenclature meaningful, so, as such, I proposed
>> alternatives.
>>
>> Ultimately, I hope that those currently performing the most development
>> should form their own opinion from the facts that have been presented when
>> it comes time for a decision to be made.
>>
>