> what about the following major.minor.patchlevel with 3.x.y as an > exception, used as: > > STABLE RELEASES > =============== > 1) release 3.x.y (e.g. 3.12.0) as stable. > we might continue providing patches, fixes, etc. in a fashion like: > - 3.12.0 (= stable) > - 3.13.0 (= major fix) > - 3.14.0 (= major fix) > - 3.15.0 (= small fix) > ... > > 2) continue development with 4.0.x. release 4.0.14 as stable with: > - 4.0.14 (= stable) > - 4.0.15 (= fix) > - 4.0.16 (= fix) > - 4.0.17 (= fix) > ... > > 3) continue development with 4.1.x, release e.g. 4.1.25 as stable with: > - 4.1.25 (= stable) > - 4.1.26 (= fix) > - 4.1.27 (= fix) > - 4.1.28 (= fix) > ... > > that's for the handling of stable releases.
So in essence, at one patchlevel a major.minor becomes stable and a new (major.minor) is begun - that would work for me and sound quite logical... A key point still would be that there could be a 4.1.24 unstable, while I begin to work on 4.2.0. After all, things are unstable at first ;) So we have two unstable in a row. After a while (we may be at 4.2.6) we can release 4.1.25 (stable) as it has matured enough. Any more comments on that? > ad 1) as a more consistent use of the major.minor.patchlevel, we could > use: > - 3.12.0 > - 3.12.1 > - 3.12.2 > ... > - 3.12.1255 > > > > DEVELOPMENT SUGGESTION A > ======================== > inside the development tree, one could do: > 4.1.0 = new dev release > 4.1.1-rc1 = major new features - exerimental - only for hardcore > testers > 4.1.1-rc2 = getting more stable > 4.1.1-rc3 = getting more stable > 4.1.1 = let more ppl test this release with its new features > > 4.1.2-rc1 = new features, new fixes, based on 4.1.1. 4.1.1. will not be > continued/patched/etc. I see where you are coming from. This is actually a three and a half version numbering scheme - but also makes sense to me. Looks like a good solution. I like this much more than suggestion B, I have to admit ;) -- the main reason is that I tend to commit very frequently, but a nightly release will probably bad to follow up on. Overall, these suggestions look easier to follow than mine. So if nobody objects, I'll implement them by mid next week. BUT... Feedback is still most welcome! Rainer > > > > DEVELOPMENT SUGGESTION B > ======================== > do not release that many devel releases but put out nightlies with > a git "short" tag (i think i've seen this on hg). [1] > > this would mean: > 4.1.0 = new dev tree is started. > 4.1.1-d12080bf3d99 snapshot/interim release 2008-03-28 big new > features! > 4.1.1-c377eb7b2a22 snapshot/interim release 2008-03-29 fixing > 4.1.1-b7b2a2515d3a snapshot/interim release 2008-03-30 fixing > 4.1.1 - now we're confident enough to make a release for testing. > > 4.1.2-10e7d626f05c - big new features snapshot/interim release > ... > 4.1.2 - we're confident - public testers wanted > ... > 4.1.25 - now we're stable - declare stable, no more features. ;) > > of course, such interim releases must not happen on a daily basis. > everyone should be free to do a recent checkout and those interim > releases could be limited to rainer feeling confident enough ;) > > > > so, what about this suggestion? > > cheers, > raoul > > [1] how to shorten the git revisions. > long: 4.1.1-d120806a4549ae6c377eb7b2a25172251fbf3d99 > 4.1.1-d12080(6a4549ae6c377eb7b2a25172251f)bf3d99 > 4.1.1-d12080...bf3d99 > 4.1.1-d12080.bf3d99 > 4.1.1-d12080bf3d99 > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. [EMAIL PROTECTED] > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. [EMAIL PROTECTED] > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
