PMC proposals/Pre-releases

2011/02/08 #2: Pre-releases

Proposal withdrawn by proposer, please do not modify.

Summary

We propose to switch to the 'release early, release often' model, by adopting '-alpha' and '-pre' versions. There is a long tradition in software, and in Open Source in particular, of making 'alpha' and 'pre' (/'beta'/'testing') releases: we feel we should employ this model.

The primary motivation is to increase the pool of testers and contributors beyond those who have successfully navigated through SVN.

As secondary motivations, we hope to increase the visibility of ongoing work, and to prevent stagnation in modules that have stalled at the testing phase.

The discussion leading to this proposal may be read in this thread.

Proposed by: Jimregan

Seconded by:

In Detail

Releases of linguistic data are quite few and far between. Mostly, this is due to a quite intensive quality control process (testvoc), which is typically carried out by a single person, alone. We wish to start releasing 'pre-releases', to both make data available in a more timely fashion, and to solicit help and feedback for quality control (when it is most needed).

We propose that these releases may contain either an '-alpha' or '-pre' tag, for situations where the likely full release date is unknown, and known, respectively.

Alpha releases are intended for packages which, for external reasons, are not yet fully operational, but where external assistance is needed.

Pre-releases are intended for packages which, aside from testvoc, are ready for public consumption, to seek help in testing.

Caveats

• Pre-releases are intended to be for testing only. Other than for routine testing matters (i.e., testvoc), and matters which could not reasonably be foreseen, they are expected to be release ready.
• Alpha releases are intended for situations where a pre-release is hindered by external factors: where some factor beyond the control of the developer (a missing tool, lack of linguistic information) prevents the completion of a pre-release. These factors must be described in an 'ISSUES' file.

Comments

Comments on the proposal are welcome. Please sign your comments using ~~~~

• There should be a list of requirements for both pre- and alpha-. And this should be included in the proposal. - Francis Tyers 12:46, 9 February 2011 (UTC)
  • Prereleases and alpha releases are pretty well understood in general. As we lack any sort of formal requirements for a release, a 'list of requirements' is a bit over the top. -- Jimregan 14:42, 9 February 2011 (UTC)
    • There are guidelines, that are _mostly_ kept to (in more than half of releases). - Francis Tyers 14:48, 9 February 2011 (UTC)
      • I'd really prefer to start with a loose definition, that can be formalised later, if required. -- Jimregan 15:02, 9 February 2011 (UTC)
        • • Even if requirements are loose, it would be nice to have them listed as part of the proposal before voting. --Mlforcada 06:00, 10 February 2011 (UTC)

• I prefer the term 'release candidate' -- Jacob Nordfalk 08:52, 10 February 2011 (UTC)
  • rc- would have been fine, and fit the same ls order sweet spot, but see below -- Jimregan 11:11, 10 February 2011 (UTC)

• Honestly, I thought this was the less contentious of the two proposals. Nobody said yes, but, equally important, nobody said no, so the matter is 'undefined'. I think the ideal would be, if anyone's interested, to try it out: if anyone's interested in proposing this, or something like it, in future, they should probably start with a real idea of what works and what doesn't. -- Jimregan 11:11, 10 February 2011 (UTC)

Voting

Please note that voting is only open to PMC members. Please vote by signing (~~~) in the relevant section.

Agree

• Jimregan

Disagree

Abstain