> On Nov 12, 2016, at 3:23 PM, Rainer Müller <rai...@macports.org> wrote: > > On 2016-11-12 21:50, Ryan Schmidt wrote: >> >>> On Nov 12, 2016, at 2:03 PM, Lawrence Velázquez >>> <lar...@macports.org> wrote: >>> >>>> On Nov 12, 2016, at 12:44 PM, Rainer Müller <rai...@macports.org> >>>> wrote: >>>> >>>> master is definitely not in a state to be released, but the >>>> roadmap should be discussed separately. Changing the maintainers >>>> would be the only breaking change we would add. If we say this >>>> absolutely requires a new 2.x release, we could also branch >>>> release-2.4 from release-2.3 and call the next release 2.4.0. >>> >>> Branching release-2.4 from release-2.3 seems fine to me. >> >> We've never done anything like that before and I don't know what all >> the consequences would be. > > At some point we will have to do this anyway, as I do not see the > possibility that all features on the current master will reach stability > at the same time. > >>> I don't think our decision on versioning should be affected (much) >>> by a desire to branch from master. >> >> One consequence that occurs to me is that people using master >> currently have version 2.3.99. If we branch 2.4 from 2.3, then when >> those users run selfupdate they would be "upgraded" to 2.4 which >> doesn't contain all the features they had been using on 2.3.99. In >> the 2 years of master development, we might have done many things, >> such as adding columns to the registry database, that would make it >> bad for the user to downgrade. > > There is no continuous selfupdate when using master, installations need > to be upgraded manually. As there is no downgrade path for the registry, > such installations will need to stay at master.
Precisely. Which is why we mustn't cause a downgrade to occur for users of master. We do actually have a "trunk" rsync directory. Isn't the purpose of that to allow users of master to selfupdate using it? I've never tried it. > We do not give any guarantees for compatibility of master with released > or future versions and this should not hold us back from making any changes. > > We increase the version of master to 2.4.99 when we branch 2.4, like we > normally do. As soon as installations of master are upgraded at least > once, they would not get the released 2.4.0. Users running master might be in the habit of running "sudo port selfupdate" regularly, as we recommend they do, which would update their ports but not base, but only occasionally manually updating their base source code and rebuilding base from it. After we update master to be 2.4.99, users would have to know to update and rebuild base manually before they selfupdate. We should communicate that to users in advance so that they don't inadvertently selfupdate update to 2.4.0. Or we should communicate how to use the trunk rsync directory, if that's not already common knowledge.
