On Wednesday, 12 December 2012 at 19:28:54 UTC, Rob T wrote:

>> 2.61.0 => bugfixes => 2.61.1
>> 2.61.0 => newfeatures => 2.62.0 beta 1
>> 2.62 => preparing for stabilizing => 2.62 rc1
>>
>> just some thoughts.
>
> A 3 point numbering system used to differentiate between the stable bug fix releases and the beta version works just fine, and there's no need to introduce descriptive symbols, although that can be useful to indicate what is stable, beta or alpha.

So I say let us stay away from beta/alpha because those mean something different for different people and we need to define what they mean in D.

1. Bug fix only (how important is backwards compatibility here [when derived from a bug])
2. Backward compatible additions
3. Vetting

This seems to be the main releases that are being talk about. For which you are probably talking about the ability to use a 3 point system.

The mapping I think people envision from this

1 & 2 => stable release
3 => dev release

[side rant]
When doing version numbering there are two main approaches I've seen used, maybe this has a formal name, but I'll call them front loaded and back loaded.

Front loaded version generally comes from having goals/milestones for a version. In this case all the work for that version comes before the release. This is generally seen pre-1.0 as that will be the stable release.

Back loaded is what generally comes from deciding on a new direction and where D currently is. In this case all the work is done within the version. This is generally seen in 2.0, software is released with the 2.xx stamp but is not fulfilling all the requirements needed to meet being the second version.
[/side rant]

I'd like to see what you envision for mapping these versions.

vetting.additions.bug?

Do we release a stable then increment vetting and develop under that (back loaded)? Or

stable.vetting.additions/bug

Do we increment stable upon release and continue increasing vetting as we release those for the volatile changes. (front loaded)

This is how I see the two approaches without wrecking havoc on current version numbers. I'll use [notes] to reference to the "A successful Git branching model" article.

---------------front loaded (2.0 still back loaded)
stable
2.61   // always release whole number as stable
2.61.1 [Seen in the master branch coming from hotfix branch]
2.61.2
dev
2.62  // develop on whole number
2.63 [not shown they only do a single stable release]
2.64 [these releases are inclusive of hotfix, feature, and release branch]
2.65 [first green circle]
2.66
2.67
rc
2.65rc1 // beat release into submission
2.65rc2 [this is the release branch]
----------------back loaded
stable
2.61.7 // always release in development
2.61.8 // continue work after release
2.61.9
dev
2.62 // always start development on whole
2.62.1
2.62.2
2.62.3
2.63
2.63.1
rc
2.62.3rc1 // beat release into submission
2.62.4rc2 // maybe change dev number

On Wednesday, 12 December 2012 at 18:25:10 UTC, Rob T wrote:
> On Wednesday, 12 December 2012 at 10:22:32 UTC, foobar wrote:
>> To summarize:
>> 2. The version scheme is meaningless. Please check out http://www.mozilla.org/en-US/firefox/channel/#firefox as an example. It's perfectly clear, you can choose what Mozilla calls a channel - i.e "release" or "beta".
>
> I agree Firefox has a meaningless version numbering system because Firefox adopted a meaningless version numbering system. I don't understand the rational behind the decision to switch from the previous one that was meaningful.
>
> What advantage do you gain by dropping a major, minor, and revision from your version numbering system?
>
>> We can put both in a two column table with high-level description of changes and links to more-detailed change logs.
>
> There's no harm in doing that, but what would be most useful is knowing if the change is a major one or a minor one or just for bug fixes.
>
>> 3. Debian is a HUGE project with lots of manpower. D is not.
>
> We all know this, but that does not mean we cannot do a lot better than we're doing now, and if we can get rid of the waste, like those endless debates that cannot be resolved with one branch, then there'll effectively be more manpower available.
>
>> I think it is enough to have two _publicly visible download channels_ - release and beta (testing). Those are the only two that should be formally defined. There is no need to define prior stages of development as people can just informally create their own local branches for their own experiments and they could also push them upstream to share with other developers without any requirement to list an executable on the official download page. The source code is available on github - if you wanted to you could pull whatever branch and build it yourself at your own risk.
>
> But that's almost what we have now, and it does not work and it never will work.
>
> The problem with only two official branches, is that one has to be for a stable version, and the other has to be for the "new stuff", but there's two kinds of "new stuff". One kind is for breaking changes, or for introducing new concepts that have not been well tested. and the other kind is for field testing new concepts that are reasonably well understood and cause no breaking changes.
>
> What real-world programmers want to have, is a reasonably stable "beta" version that they can use for real work - this is NOT for playing around with, but for making things work for real. They want the beta because it has something that the stable does not yet have.
>
> What these guys don't want, and cannot put up with for real world programming, is an unstable alpha, but that's what you are proposing we continue on with, which is exactly what we have now and it does not work.
>
> In addition, once the beta/alpha is close to ready to be released into stable, it has to be frozen for a few months, where no new features are added and only bug fixes continue on, but then you've just lost your unstable branch!
>
> Have a look at the thread on the introduction of UDA's to see what's going on, and ask yourself if a two branch system will solve that kind of never ending problem.
>
>> 4. The only official executables on the download page are for two channels - release and beta. You can grab the latest stable "release" that only gets critical bug-fixes or the monthly beta that also contains preview features such as the upcoming user-defined attributes. You can also grab previous versions of both release channels by clicking the "previous versions" link. Anything else has zero guaranties and you are required to build yourself from source.
>
> That all works fine. What I think is glaringly missing is the unstable branch, so we need at a minimum 3 branches.
>
> --rt

I really didn't want to get dragged into the versioning scheme debate as it is just bikesheding in disguise but oh well.. I'll ask in return, what's the added benefit of your scheme? I honestly see no added benefit whatsoever.
There's no intrinsic benefit compared to a changelog that lists "Jelly bean" after "Ice cream sandwich". How do you know what was added to a version? Simple, you have a "what's new" page that lists new major features denoted by "New feature:" tag and bug-fixes denoted by "Bug-Fix:" tag.
Here's an example - http://www.mozilla.org/en-US/firefox/17.0.1/releasenotes/

Regarding the important (IMO) part of the discussion - 2 vs. 3 levels - I feel I haven't explained myself properly so let me clarify:
I was taking into account what I thought was a reasonable assumption that D2 is in the process of stabilization and no major redesigns are planed. This means the "Major" version is 2 as in D2.
My stable releases are meant to be the "Minor" releases on the D2 branch. These releases can introduce new backwards-compatible features and restricted breaking changes when absolutely required _over several releases_ with _a well defined migration(*) process_ - in other words support evolution.
Major redesigns belong under a "revolution" such as the python3 effort. There is no point on setting time-lines for that. If and when we accumulate enough reasons/momentum/etc for such a major break we'll just create a new "major" version of D called D3 which right now is completely off the table.

This is _not_ exactly what we have now because now new features are introduced right away, without public field testing (the beta channel). We have no defined criteria as to when a feature is mature enough to have it's syntax/API frozen and should be graduated from beta phase and integrated into stable. That is the point of defining the process.

(*) A well defined migration path should span several stable versions and define these stages:
1. Warn the user that a feature is going away/ is going to be changed
2. Deprecate the feature and don't accept it at compilation (unless -d is used)
3. remove the feature completely.

On Wednesday, 12 December 2012 at 18:33:17 UTC, Jesse Phillips wrote:
> On Wednesday, 12 December 2012 at 10:22:32 UTC, foobar wrote:
>> To summarize:
>
>> 2. The version scheme is meaningless. Please check out http://www.mozilla.org/en-US/firefox/channel/#firefox as an example. It's perfectly clear, you can choose what Mozilla calls a channel - i.e "release" or "beta".
>
> This is a poor example as it doesn't show how the development team develops these versions.
>
> If we are going to have a branch supported separate from the beta/dev builds then we need a way to say that this stable version is newer but is not as new as the beta/dev.
>
> If we release 2.61 as a stable, we would then develop new features in which version? 2.62 beta 1? If so, when we release 2.61 with a bug fix which version do we release? 2.62? 2.61 stable 2?
>
> You are right that version numbers have absolutely no meaning, I don't remember if it was you, but they are also not as important as the process improvements. However if we assign meaning to numbers there can be benefit. Mozilla basically just did away with the Major version. (I say we do a Linux and leave the 2 then realize it has no meaning and up it to 3 when we reach the age of the 2.0 kernel)
>
> We should combine your beta with an added version number.
>
> 2.61.0 => bugfixes => 2.61.1
> 2.61.0 => newfeatures => 2.62.0 beta 1
> 2.62 => preparing for stabilizing => 2.62 rc1
>
> just some thoughts.

Per my answer to Rob:
D2 *is* the major version.
releases should be minor versions and largely backwards compatible - some evolution is allowed given some reasonable restrictions like a proper migration path over several releases.
Critical bug-fixes can go directly on stable releases but nothing else.

Other enhancements, new features, etc, go first on monthly beta versions and need to pass acceptance tests & community approval before graduating to stable. So a big feature such as "User defined attributes" can spend several cycles of beta testing and can go redesigns until everyone agrees that the final design is worthy of inclusion in the next stable release.

On Wednesday, 12 December 2012 at 19:28:54 UTC, Rob T wrote:

> The beta foobar speaks of is actually a combined alpha+beta, --rt

No. I have already addressed this point before.
Alpha is not part of the _official_ release process.

As a developer I can create my own local branch "DMD-new_feature" to experiment with some new idea I had. I can later on push this upstream and share my new cool feature with other developers to play with. besides other developers, users can also fetch these new branches and build themselves. This is done _before_ it matures enough to be included in beta testing.

> I really don't care about the numbering scheme and this is irrelevant to the topic of this discussion. We are discussing the PROCESS of development. How the releases are tagged is completely beside the point and could be named after sweet delights, cat names, Parks or even digits of PI. I really don't care and it really is _not important_.
> 

I agree that the numbering scheme should be chosen after the process is defined and not before, and numbering schemes are meaningless (like firefox's) _unless_ they represent some guarantee that the developer is willing to make. In that case the can be very effective imho (see http://semver.org/ for an example).

So if the process chosen makes guarantees about the project, those should be expressed by the version number. For example ubuntu's Server LTS guarantees 5 years of support, and the numbering scheme is year.month, so you know right away that ubuntu 8.04 is still supported right now. They could have named it Ubuntu Pluto and you could have looked up the end date for the support, but since you have to differentiate your releases anyway, you might as well use meaningful numbers.

On Wednesday, December 12, 2012 19:04:17 Joseph Rushton Wakeling wrote:
> It seems to me that while process is clearly very important, what's maybe necessary first is to identify what the actual results of the process are intended to be.  What should a 'stable version' of D actually mean, in practice? What should its lifetime be?  Should there be interim releases in-between stable versions which can introduce e.g. breaking features, and should those be treated only as beta versions or as releases in their own right?  How is that coupled (or decoupled) from releases of the library? etc.
> 
> I'd personally rather get those issues addressed out before talking about git methods, which to be honest I suspect will be similar no matter what the release model.

Agreed.

> So, with that in mind, here are some thoughts/suggestions.
> 
> People have talked about Debian's unstable => testing => stable model, but instead, why not consider something more akin to Ubuntu's LTS and interim releases?

That makes a _lot_ more sense than the unstable => testing => stable model.

I like the idea of having an LTS release at some interval (probably 1 year) where that branch has bug fix releases more or less monthly. We then have a dev release cycle where we put out a version of the master branch every 2 or 3 months or so, where it includes whatever new features we want to include but haven't been merged into the LTS branch yet. Then with the next major LTS release, we merge in all of the new stuff from the master branch so that it's essentially up to date with master (possibly modulo some newer features or other major changes if they weren't deemed ready yet). So, we then end up with the LTS/stable branch having a versioning scheme something like

2.061.1, 2.061.2, 2.061.3, 2.061.4 ... 2.062.1, 2.062.2, ...

and the master/dev branch has a versioning scheme like

2.062.dev1, 2.062.dev2, 2.062.dev3, 2.062, 2.063.dev1, ...

The releases on the master/dev branch which aren't marked with dev are then the new major LTS release, which the LTS/stable branch bases its next years worth of minor releases off of.

The exact way to name the versions probably needs some work, but the basic model sounds fairly straightforward and clean to me. We then have longer term releases for those who want stability where they still get bug fixes fairly frequently (possibly more frequently than now, since there won't be new features being added, causing more risk for releasing), and we continue to have dev releases more or less as we have been for those that want new features faster.

As for what that means for github and branching, I'd expect us to continue more or less as we have been for master except that newer features and other major changes would start out on feature branches so that they can be properly sorted out before being merged into master, and we'd actually branch when doing betas for releases and do the releases from those branches rather than master. Then the folks mananging the stable branch would merge in bug fixes as we go along, doing their minor releases whenever they feel it's appropriate.

As for the standard library and its releases, I wouldn't really expect them to be decoupled from the compiler's releases but rather that they would continue more or less as they have been. I think that it's too often the case that changes in them need to be made at the same time for it to really work to decouple them at this point.

- Jonathan M Davis

On 12/12/2012 07:47 PM, deadalnix wrote:
> No, no, please. As already stated, distro release systems intend to solve the
> exact opposite problem of ours.

Yes, I did already read your earlier email objecting to a "Debian-like" model. The thing is, it's not clear to me what actual details you're objecting to, apart from citing a distro as inspiration.

I'm not wedded to any detail of what I suggested, although certain parts of it seem common sense, but it's hard to deal with an objection that isn't backed up with details and counter-examples.

> If you want to look at what is done in the field, look at other programming languages.

Could you give concrete examples to contrast with what I've proposed?

On 12/13/2012 10:07 AM, Jonathan M Davis wrote:
> That makes a _lot_ more sense than the unstable => testing => stable model.
>
> I like the idea of having an LTS release at some interval (probably 1 year)
> where that branch has bug fix releases more or less monthly. We then have a dev
> release cycle where we put out a version of the master branch every 2 or 3
> months or so, where it includes whatever new features we want to include but
> haven't been merged into the LTS branch yet. Then with the next major LTS
> release, we merge in all of the new stuff from the master branch so that it's
> essentially up to date with master (possibly modulo some newer features or
> other major changes if they weren't deemed ready yet).

I wonder if I maybe created some confusion by conflating "LTS" and "stable" -- I don't think I should really have done that.

The problem that I see with what you describe is that it gives no clear mechanism for how breaking changes should be handled -- I don't mean the decision-making process of "Should we make this change?" but the means in which users are supported in making the shift from one LTS to another.

So, perhaps it would help if I proposed instead:

   -- A _stable_ release is what we all understand, a release that has been
      properly tested and has no outstanding bug reports at the time of first
      release, and to which only bugfixes are subsequently made

   -- LTS should refer to a _cycle_ of stable releases within which no breaking
      changes are made

   -- Successive LTS cycles should overlap so that the previous cycle is still
      receiving bugfixes for some time after the new LTS cycle begins.  In this
      way, users have a safe period in which to update their codebases to the
      new LTS.

So -- forgetting D's versioning scheme for a moment -- suppose you label a given LTS cycle with N.  Then N.0, N.1, N.2, ... would be the stable releases containing new but non-breaking features, which might be made annually, or every 6 months.  N.x.0, N.x.1, N.x.2, ... would be the bugfix-only updates to those releases, made as often as necessary.

Once LTS cycle N+1 has begun, then you stop making N.x releases and only apply further bug fixes.  Likewise, bugfixes to N.x stop getting released once N.x+1 is released.

So, if you assume a stable release annually, and that an LTS cycle lasts 3 years, you might have:

1st year    N.0.0
                - N.0.1   [bugfixes]
                - N.0.2
                  ...

2nd year    N.1.0   [non-breaking new features]
                - N.1.1
                - N.1.2
                  ...
                                         [new LTS cycle begins, maybe with
                                          breaking changes]
3rd year    N.2.0                       N+1.0.0
                - N.2.1                       - N+1.0.1
                - N.2.2                       - N+1.0.2
                  ...                           ...

4th year    N+1.1.0    [entirely moved over to new LTS]
                  - N+1.1.1
                  - N+1.1.2
                    ...

5th year    N+1.2.0                     N+2.0.0 [new LTS begins]

6th year    N+2.1.0

7th year    N+2.2.0                     N+3.0.0

            ... etc.

Of course, the timeline could be altered but the point would be that for every LTS cycle you'd have up to a year in which to switch, and _within_ every LTS cycle you would receive stable updates with bugfixes (regularly) and well-tested new features (annually, 6-monthly?).

That's surely more work for developers but is probably worth it in terms of security for users of D.  In the event that a new LTS is accompanied by no breaking changes, you might do away with the year's overlap to save the extra work.

If you want to translate the above into actual D version numbers, you could do it in the form V.N.x.y where V is the D language version (2 for the foreseeable future:-), N the LTS cycle, etc.

That leaves out "dev" releases, but you might want to number them differently anyway -- e.g. dev-YYYYmmdd or whatever.

> As for the standard library and its releases, I wouldn't really expect them to
> be decoupled from the compiler's releases but rather that they would continue
> more or less as they have been. I think that it's too often the case that
> changes in them need to be made at the same time for it to really work to
> decouple them at this point.

My feeling here was that as it stands Phobos is still somewhat more in flux than D itself, not so much in terms of breaking changes as in terms of new features being added.  So, I was wondering if it might be worthwhile to make new-Phobos-feature releases on a more regular basis at least in the short term while the library is still being expanded.  But I won't press for it too much.

On Thursday, 13 December 2012 at 15:44:25 UTC, Joseph Rushton Wakeling wrote:
> On 12/13/2012 10:07 AM, Jonathan M Davis wrote:
>> That makes a _lot_ more sense than the unstable => testing => stable model.
>>
>> I like the idea of having an LTS release at some interval (probably 1 year)
>> where that branch has bug fix releases more or less monthly. We then have a dev
>> release cycle where we put out a version of the master branch every 2 or 3
>> months or so, where it includes whatever new features we want to include but
>> haven't been merged into the LTS branch yet. Then with the next major LTS
>> release, we merge in all of the new stuff from the master branch so that it's
>> essentially up to date with master (possibly modulo some newer features or
>> other major changes if they weren't deemed ready yet).
>
> I wonder if I maybe created some confusion by conflating "LTS" and "stable" -- I don't think I should really have done that.
>
> The problem that I see with what you describe is that it gives no clear mechanism for how breaking changes should be handled -- I don't mean the decision-making process of "Should we make this change?" but the means in which users are supported in making the shift from one LTS to another.
>
> So, perhaps it would help if I proposed instead:
>
>    -- A _stable_ release is what we all understand, a release that has been
>       properly tested and has no outstanding bug reports at the time of first
>       release, and to which only bugfixes are subsequently made
>
>    -- LTS should refer to a _cycle_ of stable releases within which no breaking
>       changes are made
>
>    -- Successive LTS cycles should overlap so that the previous cycle is still
>       receiving bugfixes for some time after the new LTS cycle begins.  In this
>       way, users have a safe period in which to update their codebases to the
>       new LTS.
>
> So -- forgetting D's versioning scheme for a moment -- suppose you label a given LTS cycle with N.  Then N.0, N.1, N.2, ... would be the stable releases containing new but non-breaking features, which might be made annually, or every 6 months.  N.x.0, N.x.1, N.x.2, ... would be the bugfix-only updates to those releases, made as often as necessary.
>
> Once LTS cycle N+1 has begun, then you stop making N.x releases and only apply further bug fixes.  Likewise, bugfixes to N.x stop getting released once N.x+1 is released.
>
> So, if you assume a stable release annually, and that an LTS cycle lasts 3 years, you might have:
>
> 1st year    N.0.0
>                 - N.0.1   [bugfixes]
>                 - N.0.2
>                   ...
>
> 2nd year    N.1.0   [non-breaking new features]
>                 - N.1.1
>                 - N.1.2
>                   ...
>                                          [new LTS cycle begins, maybe with
>                                           breaking changes]
> 3rd year    N.2.0                       N+1.0.0
>                 - N.2.1                       - N+1.0.1
>                 - N.2.2                       - N+1.0.2
>                   ...                           ...
>
> 4th year    N+1.1.0    [entirely moved over to new LTS]
>                   - N+1.1.1
>                   - N+1.1.2
>                     ...
>
> 5th year    N+1.2.0                     N+2.0.0 [new LTS begins]
>
> 6th year    N+2.1.0
>
> 7th year    N+2.2.0                     N+3.0.0
>
>             ... etc.
>
> Of course, the timeline could be altered but the point would be that for every LTS cycle you'd have up to a year in which to switch, and _within_ every LTS cycle you would receive stable updates with bugfixes (regularly) and well-tested new features (annually, 6-monthly?).
>
> That's surely more work for developers but is probably worth it in terms of security for users of D.  In the event that a new LTS is accompanied by no breaking changes, you might do away with the year's overlap to save the extra work.
>
> If you want to translate the above into actual D version numbers, you could do it in the form V.N.x.y where V is the D language version (2 for the foreseeable future:-), N the LTS cycle, etc.
>
> That leaves out "dev" releases, but you might want to number them differently anyway -- e.g. dev-YYYYmmdd or whatever.
>
>> As for the standard library and its releases, I wouldn't really expect them to
>> be decoupled from the compiler's releases but rather that they would continue
>> more or less as they have been. I think that it's too often the case that
>> changes in them need to be made at the same time for it to really work to
>> decouple them at this point.
>
> My feeling here was that as it stands Phobos is still somewhat more in flux than D itself, not so much in terms of breaking changes as in terms of new features being added.  So, I was wondering if it might be worthwhile to make new-Phobos-feature releases on a more regular basis at least in the short term while the library is still being expanded.  But I won't press for it too much.

This approach looks the best to D. As we have the "problem" that some users want to see D more stable and other users want to see it evolve, to not turn into what C++ has become, this approach looks the best solution of all that were proposed here.

It will satisfy the users that like the language to be more stable for serious development, while the language can still evolve and the language devs will be able to do the things right.

if each LTS is supported for about 5 years, and with 1 year supporting the last LTS after a new one is released, D will be stable enough for serious development, what will attract much people, as the language is simply incredible, the only problem (at least with all people I know) is that it is not really stable.

While the LTS versions are supported, breaking changes can be introduced in non-LTS versions that are supported for bugfixes for... say 6 monthes, and non-breaking changes are merged on both the LTS and the non-LTS.

This will satisfy all D users... it will only require more work from the D team.