View mode: basic / threaded / horizontal-split · Log in · Help
December 11, 2012
Re: Next focus: PROCESS
On Tuesday, 11 December 2012 at 13:19:56 UTC, foobar wrote:
> First of all - Yay!
>
> There are still a few open questions that need to be decided
> before a suitable process can be defined.
>
> I'd say we should _at most_
> support _one_ previous stable version with critical bug fixes
> only.

I agree with that as well, although I think that after a new 
major "stable" release, the previously stable should be supported 
(at a minimum kept available for download) for some time until 
the new stable is fully stabilized and most people have been able 
to adopt it. It may be good enough to just and pick and choose if 
the previous stable should get certain bug fixes or not until the 
support period runs out.

> B. should we have public pre-release versions?

A lot of people will want to use the latest available changes for 
actual development, so the "testing" or "pre-release" branch 
should be public and kept reasonably stable, although anything 
can happen, so it's not considered "stable", just "stable enough" 
given that it may be supporting new features and improvements 
that have been selected for the next major stable release.

> I think we should release additional "releases" - call them 
> beta,
> pre-release, release candidates, whatever. These are for staging
> changes, allowing to field test new features and language 
> changes
> before they are made final. Also allowing users to adjust their
> code-bases.

I think you'll need at a minimum experimental branches for 
testing out new ideas, the main development branch witch is 
considered unstable (the master branch is probably best for this 
one as was suggested), a pre-release or testing branch that is 
used for preparing for the next major stable release, and of 
course the current stable branch which only receives bug fixes up 
until the next pre-release branch is merged into stable.

One more thing, is that we should adopt a version numbering 
system that is appropriate to indicate major, minor, and bug fix 
releases. The method of major.minor.revision can work well for 
us, but there may be alternatives that will work even better 
depending on what the process ends up being.

What I'd hate to see continuing, is a major new release going out 
with no indication in the version number that it is a major new 
release as opposed to a minor revision change. For example, the 
current DMD stable is 2.060, and the next release will be 2.061, 
but it includes brand new poorly tested features, and one of them 
is still being debated on, therefore it may be subject to change. 
The next release will be anything but a minor update and it 
should not even be considered as a stable release, it's more like 
a pre-release version for testing and for adoption by those who 
absolutely need the latest "reasonably stable" version for their 
development work.

--rt
December 11, 2012
Re: Next focus: PROCESS
On Tuesday, 11 December 2012 at 19:57:55 UTC, Rob T wrote:
> On Tuesday, 11 December 2012 at 13:19:56 UTC, foobar wrote:
>> First of all - Yay!
>>
>> There are still a few open questions that need to be decided
>> before a suitable process can be defined.
>>
>> I'd say we should _at most_
>> support _one_ previous stable version with critical bug fixes
>> only.
>
> I agree with that as well, although I think that after a new 
> major "stable" release, the previously stable should be 
> supported (at a minimum kept available for download) for some 
> time until the new stable is fully stabilized and most people 
> have been able to adopt it. It may be good enough to just and 
> pick and choose if the previous stable should get certain bug 
> fixes or not until the support period runs out.
>

By support I meant specifically _bug fixes_. You can already 
download all previous released versions from the website and in 
no way am I arguing to change that policy.
Even if we ever get to a point where we don't want to keep older 
releases which I doubt very much (each zip is only a few MBs and 
therefore insignificant on today's storage) - we could still 
easily just checkout the specific release tagged in git and just 
build that.

>> B. should we have public pre-release versions?
>
> A lot of people will want to use the latest available changes 
> for actual development, so the "testing" or "pre-release" 
> branch should be public and kept reasonably stable, although 
> anything can happen, so it's not considered "stable", just 
> "stable enough" given that it may be supporting new features 
> and improvements that have been selected for the next major 
> stable release.

This is precisely what I addressed bellow. we have monthly build 
of our staging branch - call them monthly betas that include new 
upcoming features that are already stable enough to be released 
to the public for field testing and are tentative for the next 
actual release but until these feature actually get to a release 
they hold no guaranties and can be further modified based on the 
wider public testing - including changes in API. Once released, 
they do hold such guaranties of API stability. So these monthly 
betas will provide preview of language changes and allow people 
to prepare for future changes and also provide feedback.

>
>> I think we should release additional "releases" - call them 
>> beta,
>> pre-release, release candidates, whatever. These are for 
>> staging
>> changes, allowing to field test new features and language 
>> changes
>> before they are made final. Also allowing users to adjust their
>> code-bases.
>
> I think you'll need at a minimum experimental branches for 
> testing out new ideas, the main development branch witch is 
> considered unstable (the master branch is probably best for 
> this one as was suggested), a pre-release or testing branch 
> that is used for preparing for the next major stable release, 
> and of course the current stable branch which only receives bug 
> fixes up until the next pre-release branch is merged into 
> stable.

See comment above. the pre-release will contain new features 
already stable enough to be consumes by the general public 
_before_ we the developers are ready to a commit finally to their 
API. E.g. Walter's release of DMD with attributes that was 
already tested and working but after release people argued about 
changing its syntax from [attributes] to @(attributes).

developers can have their own experimental branches for their own 
tests and new ideas, but once a feature reaches pre-release it 
should already be tested and working and ready for public 
consumption without commiting to a final API.

>
> One more thing, is that we should adopt a version numbering 
> system that is appropriate to indicate major, minor, and bug 
> fix releases. The method of major.minor.revision can work well 
> for us, but there may be alternatives that will work even 
> better depending on what the process ends up being.

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_.
This is one of those fundamental things that are required to 
truly understand git - versions are the _content_ (code) they 
contain and are identified by a hash of that content.
This is pure bikesheding but why not: Why not extend the 
astronomical theme to releases as well? What would you say about 
the latest Pluto release of DMD? ;)
(Yeah, I know this is already used by the eclipse project..)

>
> What I'd hate to see continuing, is a major new release going 
> out with no indication in the version number that it is a major 
> new release as opposed to a minor revision change. For example, 
> the current DMD stable is 2.060, and the next release will be 
> 2.061, but it includes brand new poorly tested features, and 
> one of them is still being debated on, therefore it may be 
> subject to change. The next release will be anything but a 
> minor update and it should not even be considered as a stable 
> release, it's more like a pre-release version for testing and 
> for adoption by those who absolutely need the latest 
> "reasonably stable" version for their development work.
>
> --rt
December 12, 2012
Re: Next focus: PROCESS
On Tuesday, 11 December 2012 at 23:15:27 UTC, foobar wrote:
> By support I meant specifically _bug fixes_. You can already 
> download all previous released versions from the website and in 
> no way am I arguing to change that policy.
> Even if we ever get to a point where we don't want to keep 
> older releases which I doubt very much (each zip is only a few 
> MBs and therefore insignificant on today's storage) - we could 
> still easily just checkout the specific release tagged in git 
> and just build that.

That's what I meant too, I agree with you on this point.

> This is precisely what I addressed bellow. we have monthly 
> build of our staging branch - call them monthly betas that 
> include new upcoming features that are already stable enough to 
> be released to the public for field testing and are tentative 
> for the next actual release but until these feature actually 
> get to a release they hold no guaranties and can be further 
> modified based on the wider public testing - including changes 
> in API. Once released, they do hold such guaranties of API 
> stability. So these monthly betas will provide preview of 
> language changes and allow people to prepare for future changes 
> and also provide feedback.

Having a pre-release build that can be downloaded and installed 
would be very nice to have if that's what you mean. Currently, to 
get DMD 2.061 "alpha" I have to jump through hoops to get it to a 
point where it is operational, and that is not so good as it 
limits severely how many users will be able to test it out.

> See comment above. the pre-release will contain new features 
> already stable enough to be consumes by the general public 
> _before_ we the developers are ready to a commit finally to 
> their API. E.g. Walter's release of DMD with attributes that 
> was already tested and working but after release people argued 
> about changing its syntax from [attributes] to @(attributes).
>
> developers can have their own experimental branches for their 
> own tests and new ideas, but once a feature reaches pre-release 
> it should already be tested and working and ready for public 
> consumption without commiting to a final API.

OK, but who has already tested it and how many people have been 
able to test it and comment on it? I was thinking more along the 
lines of how Debian does it, with a 4 staged release process: 
experimental => unstable => testing (pre-release) => stable.

We could probably do away with a  common "experimental" branch, 
leaving 3 common branches.

A common "unstable branch" will allow more people to test out 
newly introduced ideas well before they become merged into 
pre-release, and that may help avoid problems as we're seeing 
with the sudden introduction of UDA's.

I am hoping that we can have a pre-release version that will be 
stable enough to be used on real-world applications, knowing that 
some things can change but not in a major way. If I don't mind 
dealing with major changes, then I would instead make use of 
what's in the "unstable" branch, but I expect mostly compiler 
devs will be using unstable, and no one will be using it on 
anything important.

>
> 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_.
> This is one of those fundamental things that are required to 
> truly understand git - versions are the _content_ (code) they 
> contain and are identified by a hash of that content.
> This is pure bikesheding but why not: Why not extend the 
> astronomical theme to releases as well? What would you say 
> about the latest Pluto release of DMD? ;)
> (Yeah, I know this is already used by the eclipse project..)

I'm very surprised by your comment on version numbers and I hope 
you are a significant minority holder of that view.

How version numbers are assigned and what the number represents 
has to be made a defined part of the release process otherwise 
you'll end up with a meaningless random number or symbol (or 
nothing) for each new release, and the only information it will 
supply to you is "here's a new release". I don't see that as an 
improvement to the current situation, it just perpetuates the 
existing problem where users of the D compiler have no easy way 
to know if a new release is a major ground breaking one, or a 
minor one, or just a simple bug fix. In order to find out what a 
new release means in terms of the magnitude of changes, one has 
to read through a technical change log, and read through endless 
forum posts, and possibly even take a look at the commit log. Why 
not do something better than that when it's so easy to do?

For example, if I see that the stable version has been updated, I 
want to quickly know if it's a bug fix update or something more 
significant.

For mission critical applications, I'll jump on bug fix releases 
quickly, but I'll stay clear of any major releases up until it 
has had enough time to fully stabilize. I do this kind of 
filtering for all new releases of software that I use, and it's 
very easy to do when there's a version number that has meaning to 
it.

--rt
December 12, 2012
Re: Next focus: PROCESS
On Wed, Dec 12, 2012 at 02:03:56AM +0100, Rob T wrote:
[...]
> OK, but who has already tested it and how many people have been able
> to test it and comment on it? I was thinking more along the lines of
> how Debian does it, with a 4 staged release process: experimental =>
> unstable => testing (pre-release) => stable.

FYI, this is a misrepresentation of how Debian works. The actual process
is unstable => testing => stable. I.e., most new packages are uploaded
directly to unstable.

The experimental branch is for packages that aren't fully working, may
break your packaging system, contain untested code, etc.. Some stuff in
experimental is never migrated to unstable, because they're for, um,
experimenting with volatile or incomplete projects deemed unsuitable for
general use.

To apply the analogy to D development, this would be local git branches
where, say, Walter is toying around with incomplete code for a new
feature which may not even be compilable yet. The unstable branch would
be more-or-less complete, compilable code that haven't been extensively
tested yet (it more-or-less works, but may crash horribly, use at your
own risk, etc.). After a period of limited use, it gets merged into
testing, where a larger audience will begin using it. After it's been
proven in the field, then only it gets put into stable.

The experimental branch is really not needed as a formal part of the
process, since the developers can just use temporary local git branches
for that purpose without needing to push it to a public repository. So
really, the Debian process isn't really that different from what you
propose below:


> We could probably do away with a  common "experimental" branch,
> leaving 3 common branches.
[...]


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.
December 12, 2012
Re: Next focus: PROCESS
On Monday, 10 December 2012 at 23:41:25 UTC, Andrei Alexandrescu 
wrote:
> In turn, I'll be collecting thoughts and opinions in this 
> thread, distilled from previous discussions. We should develop 
> a few simple git scripts (such as git-start-new-feature or 
> git-start-bugfix etc) supported by an equally simple piece of 
> documentation describing how to start a new release, fix a bug, 
> experiment with a new feature, and such.

There may be some helpful scripts to facilitate a new workflow, 
but the examples given I feel just translate to learning a D 
specific git commands. Seriously you'll end up with a layer of 
abstraction that will make it harder for those familiar with git 
to understand and limit the ability of newer users to understand 
the state their working copy is in.

git-start-new-feature:
$ git checkout devbranch
$ git checkout -b newfeaturename

git-start-bugfix:
$ git checkout stablebranch
$ git checkout -b fixbugxxx

How these should be folded back is the harder part. For example 
the bug fix should then be into stablebranch and devbranch.

There is also the matter of pulling in changes of your stable or 
dev branch as you work, this is done with the add --rebase switch 
(and I believe opens the doors for more merge conflicts than a 
standard merge).

> (One piece that has been brought forward is 
> http://nvie.com/posts/a-successful-git-branching-model/ - 
> something to keep in mind.)

I would like to note that these simple flows do not mimic our 
world. We have three projects that need to be marked for release 
in tandem. It doesn't need address now, but it should be noted.

I think it would be cool if the idea behind workbench project 
someone started was used officially to sync dmd/phobos/dlang.org 
and provide any of these needed deployment scripts. It would add 
to the complexity but much of it is already there this would just 
make it more apparent.
December 12, 2012
Re: Next focus: PROCESS
On Wednesday, 12 December 2012 at 01:03:59 UTC, Rob T wrote:
> On Tuesday, 11 December 2012 at 23:15:27 UTC, foobar wrote:
>> By support I meant specifically _bug fixes_. You can already 
>> download all previous released versions from the website and 
>> in no way am I arguing to change that policy.
>> Even if we ever get to a point where we don't want to keep 
>> older releases which I doubt very much (each zip is only a few 
>> MBs and therefore insignificant on today's storage) - we could 
>> still easily just checkout the specific release tagged in git 
>> and just build that.
>
> That's what I meant too, I agree with you on this point.
>
>> This is precisely what I addressed bellow. we have monthly 
>> build of our staging branch - call them monthly betas that 
>> include new upcoming features that are already stable enough 
>> to be released to the public for field testing and are 
>> tentative for the next actual release but until these feature 
>> actually get to a release they hold no guaranties and can be 
>> further modified based on the wider public testing - including 
>> changes in API. Once released, they do hold such guaranties of 
>> API stability. So these monthly betas will provide preview of 
>> language changes and allow people to prepare for future 
>> changes and also provide feedback.
>
> Having a pre-release build that can be downloaded and installed 
> would be very nice to have if that's what you mean. Currently, 
> to get DMD 2.061 "alpha" I have to jump through hoops to get it 
> to a point where it is operational, and that is not so good as 
> it limits severely how many users will be able to test it out.
>
>> See comment above. the pre-release will contain new features 
>> already stable enough to be consumes by the general public 
>> _before_ we the developers are ready to a commit finally to 
>> their API. E.g. Walter's release of DMD with attributes that 
>> was already tested and working but after release people argued 
>> about changing its syntax from [attributes] to @(attributes).
>>
>> developers can have their own experimental branches for their 
>> own tests and new ideas, but once a feature reaches 
>> pre-release it should already be tested and working and ready 
>> for public consumption without commiting to a final API.
>
> OK, but who has already tested it and how many people have been 
> able to test it and comment on it? I was thinking more along 
> the lines of how Debian does it, with a 4 staged release 
> process: experimental => unstable => testing (pre-release) => 
> stable.
>
> We could probably do away with a  common "experimental" branch, 
> leaving 3 common branches.
>
> A common "unstable branch" will allow more people to test out 
> newly introduced ideas well before they become merged into 
> pre-release, and that may help avoid problems as we're seeing 
> with the sudden introduction of UDA's.
>
> I am hoping that we can have a pre-release version that will be 
> stable enough to be used on real-world applications, knowing 
> that some things can change but not in a major way. If I don't 
> mind dealing with major changes, then I would instead make use 
> of what's in the "unstable" branch, but I expect mostly 
> compiler devs will be using unstable, and no one will be using 
> it on anything important.
>
>>
>> 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_.
>> This is one of those fundamental things that are required to 
>> truly understand git - versions are the _content_ (code) they 
>> contain and are identified by a hash of that content.
>> This is pure bikesheding but why not: Why not extend the 
>> astronomical theme to releases as well? What would you say 
>> about the latest Pluto release of DMD? ;)
>> (Yeah, I know this is already used by the eclipse project..)
>
> I'm very surprised by your comment on version numbers and I 
> hope you are a significant minority holder of that view.
>
> How version numbers are assigned and what the number represents 
> has to be made a defined part of the release process otherwise 
> you'll end up with a meaningless random number or symbol (or 
> nothing) for each new release, and the only information it will 
> supply to you is "here's a new release". I don't see that as an 
> improvement to the current situation, it just perpetuates the 
> existing problem where users of the D compiler have no easy way 
> to know if a new release is a major ground breaking one, or a 
> minor one, or just a simple bug fix. In order to find out what 
> a new release means in terms of the magnitude of changes, one 
> has to read through a technical change log, and read through 
> endless forum posts, and possibly even take a look at the 
> commit log. Why not do something better than that when it's so 
> easy to do?
>
> For example, if I see that the stable version has been updated, 
> I want to quickly know if it's a bug fix update or something 
> more significant.
>
> For mission critical applications, I'll jump on bug fix 
> releases quickly, but I'll stay clear of any major releases up 
> until it has had enough time to fully stabilize. I do this kind 
> of filtering for all new releases of software that I use, and 
> it's very easy to do when there's a version number that has 
> meaning to it.
>
> --rt

To summarize:
1. Yes, I do suggest that "beta" versions will be available to 
download and prominently displayed on the download web-page.
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".
We can put both in a two column table with high-level description 
of changes and links to more-detailed change logs.
3. Debian is a HUGE project with lots of manpower. D is not. 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.
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.
December 12, 2012
Re: Next focus: PROCESS
On 12/12/12 1:37 AM, Jesse Phillips wrote:
> There may be some helpful scripts to facilitate a new workflow, but the
> examples given I feel just translate to learning a D specific git
> commands. Seriously you'll end up with a layer of abstraction that will
> make it harder for those familiar with git to understand and limit the
> ability of newer users to understand the state their working copy is in.

I disagree. I wrote a few git scripts for Facebook-specific workflows 
and a lot of people (including me) use them.

Beyond that we need to have a wiki page with workflows:

"To initiate a new feature"

"To initiate a bug fix"

"To initiate a library addition without formal review"

"To initiate a library addition with formal review"

...

> git-start-new-feature:
> $ git checkout devbranch
> $ git checkout -b newfeaturename
>
> git-start-bugfix:
> $ git checkout stablebranch
> $ git checkout -b fixbugxxx
>
> How these should be folded back is the harder part. For example the bug
> fix should then be into stablebranch and devbranch.

All of these will be part of the instructions and the macros. The branch 
names will be standardized.

> There is also the matter of pulling in changes of your stable or dev
> branch as you work, this is done with the add --rebase switch (and I
> believe opens the doors for more merge conflicts than a standard merge).

All of these should be subsections in the documentation.

"If your branch has conflicts"

"If your branch became really messed up"

...

>> (One piece that has been brought forward is
>> http://nvie.com/posts/a-successful-git-branching-model/ - something to
>> keep in mind.)
>
> I would like to note that these simple flows do not mimic our world. We
> have three projects that need to be marked for release in tandem. It
> doesn't need address now, but it should be noted.
>
> I think it would be cool if the idea behind workbench project someone
> started was used officially to sync dmd/phobos/dlang.org and provide any
> of these needed deployment scripts. It would add to the complexity but
> much of it is already there this would just make it more apparent.

What is the workbench project?


Andrei
December 12, 2012
Re: Next focus: PROCESS
On Wednesday, 12 December 2012 at 16:14:44 UTC, Andrei 
Alexandrescu wrote:
> I disagree. I wrote a few git scripts for Facebook-specific 
> workflows and a lot of people (including me) use them.

May have been a knee jerk reaction. Good to hear it has been used.

>> git-start-new-feature:
>> $ git checkout devbranch
>> $ git checkout -b newfeaturename
>>
>> git-start-bugfix:
>> $ git checkout stablebranch
>> $ git checkout -b fixbugxxx

> All of these will be part of the instructions and the macros. 
> The branch names will be standardized.

I'm not sure I follow on the name standardizing. Doesn't that 
make it so a person can only work on one bugfix and one feature 
at a time? The name used for the dev and stable branches should 
be standardized (I don't care much what master is, but I 
generally like it as the dev branch)

> All of these should be subsections in the documentation.
>
> "If your branch has conflicts"
>
> "If your branch became really messed up"

Yep, just pointing out where I see the difficulty and scripts may 
be of more use.

> What is the workbench project?
>
>
> Andrei

Found it, by Nathan Swan

http://forum.dlang.org/post/ygwzndxbwzrxzlhuooty@forum.dlang.org
December 12, 2012
Re: Next focus: PROCESS
On 12/11/2012 12:41 AM, Andrei Alexandrescu wrote:
> In turn, I'll be collecting thoughts and opinions in this thread, distilled from
> previous discussions. We should develop a few simple git scripts (such as
> git-start-new-feature or git-start-bugfix etc) supported by an equally simple
> piece of documentation describing how to start a new release, fix a bug,
> experiment with a new feature, and such.
>
> (One piece that has been brought forward is
> http://nvie.com/posts/a-successful-git-branching-model/ - something to keep in
> mind.)
>
> Please chime in with ideas and thoughts.

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.

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?

   * STABLE/Long-term support releases would be guaranteed to receive bugfixes
     and have no breaking changes for 3 years.

   * A new LTS release would be made every 2 years, so that there would be a
     1-year overlap between the current LTS release and the previous one.

   * Optionally, non-breaking new features could be included in LTS release
     updates during this timeframe, subject to strict testing.  Such new
     feature updates should only go to the latest LTS release (so, during the
     1-year overlap period, the older LTS would continue to receive bugfixes
     but not have new features added).  The process for including new features
     should probably be more liberal for Phobos than for other parts of the D
     toolchain.

   * In between LTS releases, there should be regular (3- or 6-monthly?)
     interim releases that have gone through testing and are considered
     'stable' in a working sense.  These releases _can_ make breaking changes,
     subject to strict conditions, and should be more liberal about new feature
     inclusion in general.  The idea should be that the interim releases
     converge towards the next LTS release, so the conditions for make breaking
     changes and the testing of new features both become more and more
     stringent the closer to the next LTS release you are.

   * For preference, deprecated features to be 'removed' by simply removing
     documentation and support for a feature rather than removing the feature
     itself (thinking here particularly of Phobos and Walter's observations).

The time periods involved could of course be tweaked, e.g. an LTS release might 
be supported for 5 years and be released every 3 or 4.  There could also be an 
even larger-scale cadence (10 years?) for really major redesigns.

The above reflects my personal preference that I'd rather have a language which 
is willing to continue to iron out annoying idiosyncrasies or bad design 
decisions -- but which can still provide a good stable base for development, 
making sure that there is a good overlap period between LTS releases so that 
developers have a substantial amount of time to update their codebases.
December 12, 2012
Re: Next focus: PROCESS
On Wed, Dec 12, 2012 at 07:04:17PM +0100, 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.

+1. Thanks for the reminder to not lose sight of the forest for the
trees.


> 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?
> 
>    * STABLE/Long-term support releases would be guaranteed to receive
>      bugfixes and have no breaking changes for 3 years.
> 
>    * A new LTS release would be made every 2 years, so that there
>      would be a 1-year overlap between the current LTS release and the
>      previous one.
[...]
> The above reflects my personal preference that I'd rather have a
> language which is willing to continue to iron out annoying
> idiosyncrasies or bad design decisions -- but which can still
> provide a good stable base for development, making sure that there
> is a good overlap period between LTS releases so that developers
> have a substantial amount of time to update their codebases.

I like this idea!!

I think this is much better than the current choice of either breaking
existing code and annoying existing users or living with bad design
decisions forever. One year is a good amount of time to upgrade people's
codebases, so we won't be hampered by bad design decisions in the past,
but can move forward with breaking changes. Freezing the language along
with bad design decisions is what made C++ the monster that it is today.

(Of course, the actual overlap times can be tweaked, but I definitely
support the idea of being able to introduce breaking changes *and* not
immediately alienate a good proportion of the userbase.)


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home