On Aug 12, 2013, at 1:56 PM, Leif Hedstrom <[email protected]> wrote: > On Aug 12, 2013, at 2:28 PM, James Peach <[email protected]> wrote: > >> On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <[email protected]> wrote: >> >>> On Aug 12, 2013, at 1:32 PM, James Peach <[email protected]> wrote: >>> >>>> >>> >>> I think the fixed dates is a very minor issue in comparison to the >>> compatibility ideas. I personally think it's a step in the wrong direction >>> (the rest of the OpenSource world is moving towards agile methodologies), >>> but I would not oppose fixed release dates if that's the consensus of the >>> community. It certainly does make the release process predictable. >> >> I don't think that a fast release cycle can work without strong >> compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times >> a year? The only way everyone will feel comfortable upgrading is if it a >> no-brainer and always works. > > Why do they have to be exclusive? The proposal suggested basically: > > - <n> number of releases per year, where compatibility is guaranteed. > We can make n=4, that's good. > - Once a year (or whatever, it doesn't specify), we allow to break > compatibility. > > > So, it would be safe for people to upgrade through the incremental releases > (just as has been the case for all stable releases so far). Once a year, or > whatever, we have the option to make an incompatible release. That doesn't > mean we *have* to make an incompatible release. We'd bump major version > if/when such a release gets made (my suggestions was to aim for no more than > 1/ year). > > The downside is that it can be up to 1 year before an incompatible change > gets into a release. I personally think that's a reasonable compromise, if it > can save a humongous amount of headache to try to provide automatic > migrations through every release.
Ok, I think that we are saying the same thing then. > > Does anyone other than me and James and Reindl have an opinion here? :-) > > -- Leif
