Next focus: PROCESS

[foobar]

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.