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
