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? > > 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. >
