Difference between revisions of "PMC proposals/Pre-releases"

From Apertium
Jump to navigation Jump to search
Line 40: Line 40:
*** There are guidelines, that are _mostly_ kept to (in more than half of releases). - [[User:Francis Tyers|Francis Tyers]] 14:48, 9 February 2011 (UTC)
*** There are guidelines, that are _mostly_ kept to (in more than half of releases). - [[User:Francis Tyers|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. -- [[User:Jimregan|Jimregan]] 15:02, 9 February 2011 (UTC)
**** I'd really prefer to start with a loose definition, that can be formalised later, if required. -- [[User:Jimregan|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. [[User:Mlforcada|Mlforcada]]


==Voting==
==Voting==

Revision as of 05:58, 10 February 2011

2011/02/08 #2: Pre-releases

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

Voting

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

Agree

Disagree

Abstain