llvm dev - Dec 2016 - [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

On Mon, Dec 5, 2016 at 10:42 AM, Dimitry Andric <dimitry at andric.com>
wrote:
> On 05 Dec 2016, at 19:26, Hans Wennborg via Openmp-dev <openmp-dev at
lists.llvm.org> wrote:
>>
>> There's still plenty of time left, but I'd like to get the
schedule
>> set before folks start disappearing for the holidays.
>>
>> Note that this release will also switch us to the new versioning
>> scheme where the major version is incremented for each major release
>> (i.e., when the 4.0 branch is created, trunk will become 5.0).
>
> Maybe I didn't pay enough attention, but where is the general outline
> for this versioning scheme documented?  And are we still going to do
> 4.1, 4.2, etc?
There was a long discussion around the time when the 3.9 branch was
created. I'm planning on writing a blog post to make sure everyone is
up to date.

The idea is that Tom's stable releases will keep incrementing the
"patch" part of the version numbers, just as today, so they would be
4.0.1, 4.0.2, etc.
>> If you'd like to help providing binaries and testing for your
>> favourite platform, please subscribe to the release-testers mailing
>> list [1].
>>
>> I propose the following schedule for the 4.0 release:
>>
>> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>>
>> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>>
>> - 21 February: Final tag. Binaries and release announcement a few days
later.
>>
>> Unless there are any objections, I'll post this on the web page
soon.
>
> Note that this is a pretty close follow-up to the 3.9.1 release.  There
> is a minor risk of "release burn-out" here... :)
Hopefully 3.9.1 will be done some time before 4.0.0 starts, otherwise
I agree that's not very good for the testers. I don't want to change
the schedule of the major releases though, as we've been on a nice
predictible 6-month cycle for a while now.

Thanks,
Hans

On 5 December 2016 at 18:56, Hans Wennborg via Release-testers
<release-testers at lists.llvm.org> wrote:
> The idea is that Tom's stable releases will keep incrementing the
> "patch" part of the version numbers, just as today, so they would
be
> 4.0.1, 4.0.2, etc.
Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2
instead.

Otherwise, it'll be:

* 3.9.0
* 3.9.1
* 4.0.0
* 4.0.1
* 5.0.0
* 5.0.1

With a totally redundant zero in the middle.

Unless we're planning to extend the maintenance of the 5.x branch and
release 5.1.0 *after* 6.0.0 is out, which would be a major change in
how we release LLVM. I don't think that's the plan.

cheers,
--renato

On Mon, Dec 5, 2016 at 11:00 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 5 December 2016 at 18:56, Hans Wennborg via Release-testers
> <release-testers at lists.llvm.org> wrote:
>> The idea is that Tom's stable releases will keep incrementing the
>> "patch" part of the version numbers, just as today, so they
would be
>> 4.0.1, 4.0.2, etc.
>
> Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2
instead.
I'd like to avoid 4.1 because of the potential for confusion about
whether it's a major release (as it would have been under the old
scheme) or a patch release.
> Otherwise, it'll be:
>
> * 3.9.0
> * 3.9.1
> * 4.0.0
> * 4.0.1
> * 5.0.0
> * 5.0.1
>
> With a totally redundant zero in the middle.
Yes, it has a redundant zero in the middle, but I don't think that's a
terrible thing, and it's very clear what the version number means.

The alternative would be:

3.9.0
3.9.1
4.0.0
4.1.0 <-- Can't tell from the version number what kind of release this
is.
> Unless we're planning to extend the maintenance of the 5.x branch and
> release 5.1.0 *after* 6.0.0 is out, which would be a major change in
> how we release LLVM. I don't think that's the plan.
Right, not planning to do that.