trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Sorber <sor...@apache.org>
Subject Re: [PROPOSAL] New release process
Date Tue, 13 Aug 2013 21:42:24 GMT
On Mon, Aug 12, 2013 at 5:40 PM, Leif Hedstrom <zwoop@apache.org> wrote:

> On Aug 12, 2013, at 5:10 PM, Igor Galić <i.galic@brainsware.org> wrote:
>
> >
> >
> > This was exactly my problem at first. Leif was going with his proposal
> in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to
> *just* major.minor releases (he's fixed that bit in the wiki by now)
> >
>
> Yes, I restored the major.minor.micro version concept. Sorry for
> obfuscating the issue unnecessarily. The updated proposals are still on
>
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> From what I can gather, the issue of contention is how to deal with
> incompatible changes. We're all in violent agreement that our long standing
> rule of not breaking compatibility within stable releases through the year
> is a given (e.g. 3.2.0 to v3.2.1 should always be safe).
>
> Cheers,
>
> -- Leif
>
>
I talked with Leif about this in person and I may be coming around to the
idea.

The versioning would follow http://semver.org/. The PATCH version would
essentially be used to do the version burn on a bad release vote and also
for the LTS versions before the next MAJOR release. The LTS release (which
is a new wrinkle Leif mentioned and I added to the wiki) would be something
the more conservative amongst us. Those who chose to run LTS could test the
other releases as if they were new feature dev releases leading up to the
next LTS release. The more adventurous would run the MINOR updates as they
came out quarterly. It's kinda like the best of both worlds in a way.

We just need to make sure to keep Alan committing on the
incompatible-next-major-release branch. :)

Mime
View raw message