Next focus: PROCESS
Rob T
rob at ucora.com
Tue Dec 11 11:57:54 PST 2012
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.
> 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.
> 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.
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.
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
More information about the Digitalmars-d
mailing list