On 6/5/13 8:44 AM, Keith Turner wrote:
On Tue, Jun 4, 2013 at 10:49 PM, Josh Elser <josh.el...@gmail.com> 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.