View mode: basic / threaded / horizontal-split · Log in · Help
December 13, 2012
Re: Next focus: PROCESS
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)
December 13, 2012
Re: Next focus: PROCESS
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
December 13, 2012
Re: Next focus: PROCESS
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.
December 13, 2012
Re: Next focus: PROCESS
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.
December 13, 2012
Re: Next focus: PROCESS
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.
December 13, 2012
Re: Next focus: PROCESS
> 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.
December 13, 2012
Re: Next focus: PROCESS
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
December 13, 2012
Re: Next focus: PROCESS
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?
December 13, 2012
Re: Next focus: PROCESS
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.
December 13, 2012
Re: Next focus: PROCESS
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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home