On 6/3/2016 9:35 AM, Olivier Dugeon wrote: > Hi Lou Jafar, > > Well, it becomes hard to follow this new numbering schema. > Probably so
> So, why not using the traditional odd/even numbering used by many open > source project, eventually combine wiht #year#month#day introduce > recently ? This will be simpler and compatible with the history of > quagga i.e. from the beginning, quagga release start in 0.9x (which > could be considered as an even number) and recently release the > 1.0.20160315 which is an odd number (i.e. the 0 after the dot). Odd > number stand for YE edition and Even number for CE edition. So that, > next CE will be 1.1.2016#month#day. And the next YE edition will be > 1.2.#year#month#day > > What do you thing ? > How about: YE uses the current date based scheme and ce uses <CERel#><CEmaint#>.Base-YEVersion So the first CE version would be 1.0.20160315 and the next might be based a YE Aug 3 release and be 2.0.20160803 Lou > Regards > > Olivier > > Le 03/06/2016 14:54, Lou Berger a écrit : >> Hi Jafar, >> >> >> On 6/2/2016 5:16 PM, Jafar Al-Gharaibeh wrote: >>> On 6/2/2016 11:43 AM, Donald Sharp wrote: >>>> How do the releases relate to each other? Not sure if it is a >>>> problem. Keep numbering disconnected since we don't currently have CE >>>> and YE connected? >>> This boils down to the question of how much different YE from CE is. >>> Different numbering schemes will give the impression that we have >>> completely different versions of Quagga. That is going to be confusing. >>> I don't think that is the case, and I don't think that is the direction >>> we want to take. This is the reason I suggested the comment (CE is a >>> superset of YE...) >> I think CE being a superset of YE makes sense. >> >>> in the document. The vast majority of patches (if not >>> all) should make their way into both releases. With CE having a shorter >>> release cycle, such updates will show up there first typically. We >>> shouldn't allow code/features divergence to keep things simple for both >>> maintainers and users. Some new/adventurous/controversial features that >>> only get a simple majority vote are good examples of features that will >>> be in CE but not in YE for an "extended" period of time. They either >>> stay there until they are deemed to be worthy of inclusion of YE, or >>> continued to be experimental for more time. In some cases we might even >>> get to the point where a feature should be dropped altogether if it >>> proves to be problematic or un-useful. >> I also think this is right. >>> The point is: we shouldn't allow bug fixes, "small" patches, or any >>> agreed upon (super majority) patches to make it to CE and slip away >>> cycle after cycle without including them in YE. >> It all depends on how long/what is needed to go from majority decision >> to unanimity. (And be considered by those driving YE.) This may be a >> very short time or, as you point out above, never. >> >>> YE should be brought up >>> to speed with CE every YE release. >> Another way of looking at this, without impacting the YE process, is >> that a CE release will always include all patches/features of the >> existing (previous) YE release. I think this is the intent of the >> current CE process, but it would be good to make this explicit. >> >>> Some new features might be carried >>> over a few cycles before they get included in YE but that doesn't mean >>> CE and YE should have release numbers completely independent of each >>> other. >> Given that CE is always a superset of YE, this seems reasonable and >> manageable. >> >>> They should have something in common. Here is one idea I have >>> regarding numbering releases: >>> >>> Quagga-CE-Major.Minor-CEMajor.CEMinor >>> Quagga-YE-Major.Minor >>> >>> Identical releases: >>> Quagga-CE-1.0-0.0 >>> Quagga-YE-1.0 >>> >>> Add minor feature X to CE >>> Quagga-CE-1.0-0.1 >>> Quagga-YE-1.0 >>> >>> Add minor feature Y to CE >>> Quagga-CE-1.0-0.2 >>> Quagga-YE-1.0 >>> >>> Move feature Y to YE >>> Quagga-CE-1.1-0.1 >>> Quagga-YE-1.1 >>> >>> As you can see, CE major and CE minor moves on their own. But whenever a >>> patch is integrated with YE, the associated numbers are carried over to >>> the main Major/Minor numbers. >> At a high level, I think this is workable, with the caveat that I think >> hyphens in version numbers aren't great, so how about just using another >> period? I think this would yield more intuitive release numbering. >> >> Also as CE is a time based release, changing CE rev number based on >> features doesn't work so well. In the current proposed process, CEmajor >> would change 2X a year, while CEMinor would change as needed for bug fix >> minor releases. so versions would be: >> >> - initial rel >> Quagga-CE-<YE-current-version>.1.0 >> >> - 6 mo later >> Quagga-CE-<YE-current-version>.2.0 >> >> - maint. release >> Quagga-CE-<YE-current-version>.2.1 >> >> - 6 mo after 2.0 >> Quagga-CE-<YE-current-version>.3.0 >> >> You'll note that ce numbers didn't change when YE rev changes. Another >> option is that CEmajor resets to 1 on a change in YE version. And would >> look like: >> >> -Quagga YE release >> Quagga-YE-<ye-version1> >> >> - initial rel >> Quagga-CE-<ye-version1>.1.0 >> >> - 6 mo later >> Quagga-CE-<ye-version1>.2.0 >> >> -Quagga YE release >> Quagga-YE-<ye-version2> >> >> - maint. release >> // main release on prior ce release so ye rev doesn't change >> Quagga-CE-<ye-version1>.2.1 >> >> - 6 mo after 2.0 >> Quagga-CE-<ye-version2>.1.0 >> >> I think this works too. >> >> What do you (anyone) think? >> >> Lou >> >>> Cheers, >>> Jafar >>> >>> _______________________________________________ >>> Quagga-dev mailing list >>> [email protected] >>> https://lists.quagga.net/mailman/listinfo/quagga-dev >>> >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> > _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
