+ 1 for the suggestion We could have something close to what Linux kernel does, having one kernel version as LTS and the other versions as non-lts. I also feel that when patches are sent we could segregate them based on the severity. For eg: new features could go in to a separate branch/repo (eg: quagga-next) and the stability features etc which affects every version could go into the stable branch/repo. Something which is followed in the Linux kernel process.
Just my thoughts ! Thanks, - Balaji On Tue, May 24, 2016 at 12:36 AM, Jafar Al-Gharaibeh <[email protected]> wrote: > +1 > > On 5/23/2016 12:45 PM, Donald Sharp wrote: > > +1 > > donald > > On Sat, May 21, 2016 at 3:31 PM, Lou Berger <[email protected]> wrote: > >> So in thinking about the problems we are discussing this and a >> little bit more, considering the comments made on the list as well >> as the ubuntu link I sent yesterday[1] a few things struck me: >> ([1] https://wiki.ubuntu.com/TimeBasedReleases) >> >> 1) Having stable release is most import to some in the community >> >> 2) Having a way of getting fixes/changes/new features in a release >> in a predictable time frame is most import to some in the >> community >> >> 3) We are not leveraging those in the community with an "adventurous >> spirit" [1] who are willing to review/test the most current >> development version >> >> 4) Others have been down this road before, and we/I could learn from >> them >> >> While #1 and #2 seem to be in conflict of each other, I think the >> ubuntu community has a fine answer to this i.e., two editions. So >> what do folks think about following a similar approach and having: >> - Long Term Edition (LTE) >> - Cutting Edge Edition (CE) >> >> LTE could live in /releases/LTE/... branch tree, follow the >> existing/old process, including in release schedule. LTE versions >> could be based on the current scheme e.g., 1.0.20160309, or simply >> year based 2016.<rev#>. >> >> CE could live in /releases/CE/... branch tree, follow the new >> process (some details still to be documented), and be released every >> N months -- Ubuntu uses N=6, I was hoping for 4 -- and have maintenance >> releases as needed. Release numbers could increment on each time >> based release (2.0 is the next one) and the number after the decimal >> place could be used for maintenance. "rcN" would be used for >> release candidate branches assuming there is a pre-release >> stability branch/period. >> >> To address #3 above, master could be the place where patches go >> once acked in the new process, and /release-candidate/CE/<rel#>.rc0 >> could be branched from master every N months. Once there is a >> release could be tagged and placed in /releases/CE/<rel#> which >> would also as the head for any maintenance releases. RC branches >> could be deleted on release, or left around for a period of time. >> There would also need to be a /releases/LTE/master that contains >> patches acked per the existing/old process. >> >> BTW the related quote from [1] on this topic is great and something I >> think worth aspiring to: >> Ubuntu users are a diverse bunch, and given the chance, history >> shows that they will test new features thoroughly simply by >> using and experimenting with their systems. You should take >> advantage of the adventurous spirit of users who track the >> development branch, and give them a chance to help you test. >> >> Obviously this is just an outline / straw man at this point, but >> I'd nonetheless be very interested in thoughts/reactions to this. >> >> So please disagree/agree/improve/comment/etc. >> >> Lou >> >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> > > > > _______________________________________________ > Quagga-dev mailing > [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
