----- Original Message ----- > On Mon, Aug 12, 2013 at 4:05 PM, Leif Hedstrom < [email protected] > wrote:
> > On Aug 12, 2013, at 3:40 PM, Igor Galić < [email protected] > wrote > > > > > > > > > > > > ----- Original Message ----- > > > >> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom < [email protected] > > > >> wrote: > > > >> > > > >>> e currently merge master into a dev branch to make a dev release. I > > >>> feel > > > >> like master and dev should be synonymous. > > > > > > > > I never quite understood why Leif felt the need to create a (temporary) > > > > -dev release branch. (but then I'm only starting to comprehend git) > > > That was a mistake. However, the 3.3.x branch had a real purpose for my > > RM'ing, just as the "4.x" branch in the WIki propopsal: > > > Imagine that you are making a release out of Master. You "git pull" it, > > look > > at the changes (hopefully), make some tests, build it, etc., maybe fix a > > bug > > or two. In the mean time, Phil commits 100 changes to master. What do you > > tag now for your release? > > > Granted you can tag as soon as you start your process, and as you make > > changes, fixes or whatever, you retag accordingly. The 3.3.x branch was > > made > > to make this process easier. > > > To be honest, I don't care about this at all. The 3.3.x branch was a tool > > to > > make my life easier, if other RMs have better tools or other methodologies, > > by all means, use those. Neither of the proposals or changes depend on > > this, > > and I hope we can avoid getting hung up on technicalities on how git works > > ;). > > > > > > > >> Ifor software of this nature. 1 a year is maybe too little from a > > > >> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 > > >> times > > > >> a year seems reasonable to me. Probably closer to 2. > > > > > > > > really? even two seems too much to me, but maybe growing up with httpd > > > > I'm thinking too conservatively. > > > Fwiw, we had these discussions early on, and the general consensus was the > > releasing early and often was the way to go. We can change that, it's what > > a > > healthy community is all about. Fwiw, HTTPD releases fairly often: 25 > > releases of v2.2 and already 6 releases for v2.4. The latter is roughly 4 > > releases per year (2.4.0 was released early 2012, right ?). What I think > > HTTPD did different was very long times between major relies (v2.2 to > > v2.4). > > I think I just had an epiphany about your proposal. I think there are two > pieces here that combined have confused me, and maybe others. You'd like to > make more stable "micro" releases, up to 4 times a year. Then you'd also > like to roll the micro release number into the minor number. So instead of > 3.4.1 we just have 3.5. Or am I even further in the weeds now? This was exactly my problem at first. Leif was going with his proposal in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to *just* major.minor releases (he's fixed that bit in the wiki by now) But that's where he lost at least a couple of us (me and Phil, and probably a good number of those "following" the thread but not commenting yet). The reason was simply because it conflated two concepts. Those two concepts however have no meaning once we put this new Release Process into place. You know, after we decided what it's supposed to look like. Which is what we're trying to do right now ;) > > Cheers, > > > -- leif > -- i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: [email protected] URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
