Hi Lou Jafar, Well, it becomes hard to follow this new numbering schema.
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 ? 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
