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.
