llvm dev - Jun 2016 - [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Richard suggested that since we do time-based rather than
> feature-based releases, the distinction between a release with or
> without major changes is arbitrary, and we should move to a scheme
> where we update the major version number on each release (4.0, 5.0,
> etc.) with minor releases in between (4.1, 5.1, ..).
If we are truly committed to doing time-based releases, we can switch
to time-based version numbers, Year.Month, for example, if we were to
release in June it would be 16.06.  We can use an extra digit for
minor releases.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at
gmail.com>*/

On Fri, Jun 24, 2016 at 5:43 PM, Dmitri Gribenko via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Richard suggested that since we do time-based rather than
> > feature-based releases, the distinction between a release with or
> > without major changes is arbitrary, and we should move to a scheme
> > where we update the major version number on each release (4.0, 5.0,
> > etc.) with minor releases in between (4.1, 5.1, ..).
>
> If we are truly committed to doing time-based releases, we can switch
> to time-based version numbers, Year.Month, for example, if we were to
> release in June it would be 16.06.  We can use an extra digit for
> minor releases.
>
This would mirror other projects doing the same, so there is precedent.
Although radically different from the current model, I think it has some
merit.  When people report bugs with 3.1, its actually hard to estimate how
it is (roughly estimating it via ~6mo release cycle does really work).
This would certainly make it easier.

Its a good alternative though it does mean that we no longer have the
ability to indicate a major shift.  However as Chris already pointed out,
LLVM is much more stable these days and perhaps worrying about major shifts
which are unseen is looking for a problem to solve rather than solving a
problem at hand.

+1 on this suggestion.


> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at
gmail.com>*/
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160624/9e97d78e/attachment.html>

On Fri, Jun 24, 2016 at 5:55 PM, Saleem Abdulrasool
<compnerd at compnerd.org> wrote:
> On Fri, Jun 24, 2016 at 5:43 PM, Dmitri Gribenko via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>>
>> On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > Richard suggested that since we do time-based rather than
>> > feature-based releases, the distinction between a release with or
>> > without major changes is arbitrary, and we should move to a scheme
>> > where we update the major version number on each release (4.0,
5.0,
>> > etc.) with minor releases in between (4.1, 5.1, ..).
>>
>> If we are truly committed to doing time-based releases, we can switch
>> to time-based version numbers, Year.Month, for example, if we were to
>> release in June it would be 16.06.  We can use an extra digit for
>> minor releases.
>
>
> This would mirror other projects doing the same, so there is precedent.
> Although radically different from the current model, I think it has some
> merit.  When people report bugs with 3.1, its actually hard to estimate how
> it is (roughly estimating it via ~6mo release cycle does really work). 
This
> would certainly make it easier.
>
> Its a good alternative though it does mean that we no longer have the
> ability to indicate a major shift.  However as Chris already pointed out,
> LLVM is much more stable these days and perhaps worrying about major shifts
> which are unseen is looking for a problem to solve rather than solving a
> problem at hand.
>
> +1 on this suggestion.
I'm not a fan of this idea. While I can see the reasoning behind it, I
think we would end up with pretty confusing-looking version numbers. I
suppose it's too radically a departure from the usual schemes for my
taste.

Thanks,
Hans