Next focus: PROCESS

[Rob T]

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