I have been having discussions with various members of the development community in regards to changes to the way we manage open source Asterisk releases. The changes that we eventually decide on will determine how we manage the 1.6 version of Asterisk. I will be posting much more detailed information about 1.6 in the near future. What I'm looking for right now is some opinions on version numbering. Part of the working plan for Asterisk 1.6 involves making release candidates for every 1.6.X release, so that various community members can help with doing regression testing on the changes before making the release. I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. Another proposal has been using 1.5 to indicate that it is a release candidate. For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the release candidates for the upcoming 1.6.3 release. What is your opinion? I certainly want the release naming to be as obvious as possible. -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc.
I second calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20071010/e613b11e/attachment.htm
Russell Bryant wrote:> I have been having discussions with various members of the development community > in regards to changes to the way we manage open source Asterisk releases. The > changes that we eventually decide on will determine how we manage the 1.6 > version of Asterisk. I will be posting much more detailed information about 1.6 > in the near future. > > What I'm looking for right now is some opinions on version numbering. Part of > the working plan for Asterisk 1.6 involves making release candidates for every > 1.6.X release, so that various community members can help with doing regression > testing on the changes before making the release. > > I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. > > Another proposal has been using 1.5 to indicate that it is a release candidate. > For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the release candidates for > the upcoming 1.6.3 release. > > What is your opinion? I certainly want the release naming to be as obvious as > possible. > >I think that using 1.5.x as the name for a release candidate for 1.6 is pretty close to as unintuitive as it can possibly be. 1.6.Xrc-Y is a strikingly MORE intuitive naming scheme for 1.6 release candidates. N.
Russell Bryant wrote:> I have been having discussions with various members of the development community > in regards to changes to the way we manage open source Asterisk releases. The > changes that we eventually decide on will determine how we manage the 1.6 > version of Asterisk. I will be posting much more detailed information about 1.6 > in the near future. > > What I'm looking for right now is some opinions on version numbering. Part of > the working plan for Asterisk 1.6 involves making release candidates for every > 1.6.X release, so that various community members can help with doing regression > testing on the changes before making the release. > > I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc.yes for me.> > Another proposal has been using 1.5 to indicate that it is a release candidate. > For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the release candidates for > the upcoming 1.6.3 release. >eek. no.> What is your opinion? I certainly want the release naming to be as obvious as > possible. >Julian
Russell Bryant wrote:> I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. > > What is your opinion? I certainly want the release naming to be as obvious as > possible. > >Then I think that would be the rc1,rc2 style then. Doug -- Ben Franklin quote: "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety."
On Wednesday October 10 2007 2:15 pm, Doug Lytle wrote:> Russell Bryant wrote: > > I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. > > > > What is your opinion? I certainly want the release naming to be as > > obvious as possible.I would say the rc-1, rc-2 is about as obvious as it gets and would get my vote. JohnM -- John Millican Senior Partner Director of Technology Sentinel Communications PO Box 9 Wentworth, NH 03282 Phone (603) 764-9163
On Wed, Oct 10, 2007 at 12:54:42PM -0500, Russell Bryant wrote:> What is your opinion? I certainly want the release naming to be as obvious as > possible.Wikipedia has something to say on this (by which, of course, I mean me :-)... The traditional approach to this is, roughly 1.5.8 1.5.9 1.5.10 1.5.11 == 1.6a1 1.6a2 1.6a3 1.6a4 == 1.6b1 1.6b2 1.6b3 1.6b4 == 1.6rc1 1.6rc2 1.6rc3 == 1.6.0 1.6.1 1.6.2 ... The important points (IME) are these: 1) the first release of a transition level is exactly equivalent to the differently numbered release it replaces. This is most important coming out of Release Candidates: you *must not make any changes* between your last RC and your production release. If you do, it's really another beta. (The common distinction between betas and RC's is that betas are permitted new features, but RC's come after the feature freeze, and aren't.) 2) If you promote a level, and it turns out not to be robust enough to support it, you can either demote it and try again, or just march ahead and fix the bugs, but you can't reuse a version number for different code. 3) Version numbers serve 2 purposes: they're a contract with the user about the expectations they can have reasonably about the release as it sits -- if I see something that's an RC2 coming off 5 betas, then I can make some assumptions about how stable and reliable I think that code's likely to be -- if the release manager hasn't een playing fast and loose with the numbering. (Specifically, if you make any changes between your last beta and your first RC, then it's not really an RC; it's another beta.) And secondly, they're a contract between users and technical support, so that TS knows *exactly* what code base the user has and can debug problems reliably -- which is even more critical in the open source world where your TS team is other users than it is in commercial software. Just my thoughts from observation of 25 years of development... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
rc1, rc2 is the best choice for me. Best Regards. Emiliano Vazquez. ----- Original Message ----- From: "Russell Bryant" <russell at digium.com> To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com> Sent: Wednesday, October 10, 2007 2:54 PM Subject: [asterisk-users] Opinions on Release Numbering>I have been having discussions with various members of the development >community > in regards to changes to the way we manage open source Asterisk releases. > The > changes that we eventually decide on will determine how we manage the 1.6 > version of Asterisk. I will be posting much more detailed information > about 1.6 > in the near future. > > What I'm looking for right now is some opinions on version numbering. > Part of > the working plan for Asterisk 1.6 involves making release candidates for > every > 1.6.X release, so that various community members can help with doing > regression > testing on the changes before making the release. > > I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. > > Another proposal has been using 1.5 to indicate that it is a release > candidate. > For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the release > candidates for > the upcoming 1.6.3 release. > > What is your opinion? I certainly want the release naming to be as > obvious as > possible. > > -- > Russell Bryant > Senior Software Engineer > Open Source Team Lead > Digium, Inc. > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
Russell Bryant wrote:> I have been having discussions with various members of the development community > in regards to changes to the way we manage open source Asterisk releases. The > changes that we eventually decide on will determine how we manage the 1.6 > version of Asterisk. I will be posting much more detailed information about 1.6 > in the near future. > > What I'm looking for right now is some opinions on version numbering. Part of > the working plan for Asterisk 1.6 involves making release candidates for every > 1.6.X release, so that various community members can help with doing regression > testing on the changes before making the release. > > I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. > > Another proposal has been using 1.5 to indicate that it is a release candidate. > For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the release candidates for > the upcoming 1.6.3 release. > > What is your opinion? I certainly want the release naming to be as obvious as > possible. >If I remember what was discussed in a recent VoIP users conference, you guys (being digium) were considering moving to a more rapid release schedule similar to how the linux kernel is currently released. IE 1.6.4 would likely contain additional features over 1.6.3 and 1.6.3.1 would contain bug fixes for 1.6.3. That being the case I think the 1.5.x scheme would get confusing very quick. Example: is 1.5.3.1 the second RC for 1.6.3 or the first RC for 1.6.3.1? I would vote for the 1.6.3.x-rc1,rc2 etc scheme. This does begs the question of the purpose of the odd number releases 1.1.x,1.3.x,1.5.x (which don't exist). Will asterisk continue to increment in even number releases just because or will odd numbers be used at some point? -Dave
My opinion: 1.4 is a branch. current trunk should be called 1.5 1.5 should be 1.5.1.1, 1.5.1.2 ,1.5.1.3,1.5.2 In the above, X.X.Y denotes the "stable" version. Any changes to that code, would use the next point value. 1.5.1.Z You do not change to 1.5.2."0" until it has been tested, thus 1.5.2 would be the stable release of the last 1.5.1.Z. You could think of it as beta1, Beta2, RC1, RC2, etc. just without all those nasty letter in the version number. You could also drop the "1"s and move everything over one spot in my opinion. At a year between releases (not a slam by the way) I think you could use full integer increments on the versions. -- -- Steven http://www.glimasoutheast.org "Russell Bryant" <russell at digium.com> wrote in message news:470D11E2.6080203 at digium.com...>I have been having discussions with various members of the development community > in regards to changes to the way we manage open source Asterisk releases. The > changes that we eventually decide on will determine how we manage the 1.6 > version of Asterisk. I will be posting much more detailed information about 1.6 > in the near future. > > What I'm looking for right now is some opinions on version numbering. Part of > the working plan for Asterisk 1.6 involves making release candidates for every > 1.6.X release, so that various community members can help with doing regression > testing on the changes before making the release. > > I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. > > Another proposal has been using 1.5 to indicate that it is a release candidate. > For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the release candidates for > the upcoming 1.6.3 release. > > What is your opinion? I certainly want the release naming to be as obvious as > possible. > > -- > Russell Bryant > Senior Software Engineer > Open Source Team Lead > Digium, Inc. > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
On Wed, 10 Oct 2007 12:54:42 -0500, Russell Bryant wrote:> I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc. > > Another proposal has been using 1.5 to indicate that it is a release > candidate. For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the > release candidates for the upcoming 1.6.3 release.the former is more obvious than the latter. i kind of like asterisk's release numbering mechanism where the even numbered dot releases are stable/production while the odd numbered ones are for development. -- Regards, /\_/\ "All dogs go to heaven." dinesh at alphaque.com (0 0) http://www.openmalaysiablog.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+
On Wednesday 10 October 2007 12:54:42 Russell Bryant wrote:> I have been having discussions with various members of the development > community in regards to changes to the way we manage open source Asterisk > releases. The changes that we eventually decide on will determine how we > manage the 1.6 version of Asterisk. I will be posting much more detailed > information about 1.6 in the near future. > > What I'm looking for right now is some opinions on version numbering. Part > of the working plan for Asterisk 1.6 involves making release candidates for > every 1.6.X release, so that various community members can help with doing > regression testing on the changes before making the release. > > I proposed calling the release candidates 1.6.3-rc1, 1.6.3-rc2, etc.One of the problems with this traditional approach is that it's not obvious unless you know what "rc" means. In the case of someone new to software development, I want them never to assume that "1.6.0-rc2" means "1.6.0 plus something else, presumably desireable to have". Note that this isn't without precedence; netatalk was distributed for years as netatalk-1.3+asun. It would be perfectly reasonable to assume that "rc" was someone's initials.> Another proposal has been using 1.5 to indicate that it is a release > candidate. For example, 1.5.3, 1.5.3.1, 1.5.3.2, etc., would be the release > candidates for the upcoming 1.6.3 release.This method is no less obvious than "rc1" for the untrained and ensures that people who do not wish to become guinea pigs will remain out of that arena (i.e. if they only choose the version that sorts to the bottom of the directory, they will always be running a release). The universal problem is that we'd like people who know little to pick the right version, with no training (and yes, the system using "rc" to indicate release candidates is also a matter of training, the abbreviation is not obvious to the untrained). -- Tilghman