Next focus: PROCESS

[foobar]

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