Release planning for 2.063

[Russel Winder]

On Mon, 2013-02-25 at 19:47 +0100, Johannes Pfau wrote:
[…]
> Feature freeze     4 mar 2013
> Beta 1             4 mar 2013
> RC 1               18 mar 2013
> RC 2               25 mar 2013
> Final release      1 apr 2013 

I have yet to find an organization that used this sort of scheduling
successfully. Feature freeze fine, beta 1 fine. RC is a release
candidate not a beta. If no-one finds a problem with a release candidate
it is relabelled the final release. Thus scheduling an RC2 is a failure
of RC1 to be an RC at all.

Successful releases will schedule a feature freeze and release a beta
and push people to use it and report bugs. This entails getting is
packaged and out via places like the D release page and the Debian
package archive as snapshot releases. There might be a series of betas
2, 3, 4,… as required bug fixes are made, each getting a full snapshot
release. Then an RC is declared which is a real RC not a wrongly
labelled beta. Make the final release when it is ready to an approximate
schedule not to a mandated day.

Obviously the Debian model is one extreme: declare a freeze and then
take well over a year to fiddle around and not update the rolling
release thereby pissing off many people who ship over to Fedora. I am
close to this point myself.

Another extreme is to do what Eclipse does which is to simply release on
a given date and then patch until the following year. This has a habit
of annoying a lot of people as a release ends up having masses of
annoying bugs that do not get fixed. Leading people to ship over to
IntelliJ IDEA, Wing IDE, Code::Blocks, MonoDevelop.

So schedule the freeze/beta then specify a date for the release
candidate sequence to start and a moratorium period for an RC to be
relabeled unless a problem is found.
[…]
> A long term release plan could then look like this:
> http://wiki.dlang.org/User:Jpf/Release_Schedule

I would suggest that having a schedule such as this is to lead to
problems. It is overcomplicated and over-bureaucratic. If the intention
is to move to timeboxing of the minor releases, just allow bug fix
releases on an as needed basis. Allowing for s.XXX.Y is a good thing as
it means there is a route for fixing trivial things instantly rather
than waiting for the next minor release, but no need to schedule them.

[…]

Moving to a timebox minor release program really necessitated putting
effort into a Debian/Ubuntu/Mint repository, a Fedora repository, and a
MacPorts/Brew repository, as well as Windows and OSX installers,
ensuring the numbering scheme is monotonic increasing. If people can
sign up to the programme using the systems packaging then take up is
more likely(*). The point here is to be able to make it as easy as
possible for *new* people to sign up. The current folks are hardcore
people who will do stuff no matter how painful. The intention has to be
to increase the D using community and this requires triviality of
signup.

Groovy/Grails/Gradle/Griffon (Gr8) community has gone a different route,
necessitated by the slowness of the official Debian and Fedora release
system and the unwillingness to support the variety of systems (though
the MacPorts stuff always worked well). An individual "scratched an
itch" and created a Bash/Vert.x based release and distribution system,
called GVM. This has swept through the community (even Windows people)
and is now the standard mechanism. New releases are available to all
within hours and roll-back to any earlier release is trivial, as is
having multiple releases co-resident.

I strike me that a D/vibe.d system modelled on GVM, must be relatively
straightforward. The question is not so much can vibe.d compete with
vert.x in that part of the functionality, but can D compete with Bash in
the client functionality. In particular can the client self update?(**)


(*) I know Windows users do not understand having a system packaging
infrastructure.

(**) My irritation over GVM's use of bash is that it breaks my Bash
initialization, so I have to hack it. But I am now happy my hack is
sustainable so use GVM over Debian packaging for these Gr8 systems.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130226/476415b2/attachment.pgp>