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

[Michał Górny via llvm-dev]

On Mon, 5 Dec 2016 12:07:25 -0800
Hans Wennborg via lldb-dev <lldb-dev at lists.llvm.org> wrote:

> On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin <renato.golin at linaro.org> wrote:
> > On 5 December 2016 at 19:56, Hans Wennborg <hans at chromium.org> wrote:  
> >> 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.  
> >
> > But if the versioning scheme is different, users will have to
> > understand what it means anyway.
> >
> > Until now we had a weird and very unique logic, and we're moving to a
> > more sensible logic, because it's similar to what some other projects
> > are doing.
> >
> > I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
> > that used to be weird before.
> >
> > After a few releases everything will be clear anyway... I really don't
> > want to make the foreseeable future weird again to avoid a potential
> > misunderstanding for one or two releases.
> >
> > Let's just be brutally clear in all release communications and
> > hopefully people will understand.
> >
> >  
> >> 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.  
> >
> > No, that has a redundant zero, too.
> >
> > The alternative is:
> >
> > 3.9.0
> > 3.9.1
> > 4.0
> > 4.1
> > 5.0
> > 5.1  
> 
> I'm worried that users will, with some reason, think that the 4.1 and
> 5.1 releases are the same kind as 2.1 and 3.1 :-/

Just do 4a, 4b, 4c ;-). Everyone will be as confused as possible ;-).

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161206/b2697d1e/attachment.sig>