RE: release methodology

["Andre Carregal" <carregal@...>]

Hi,

What about settling for something like the usual alfa/beta/rc/gold cycles
(Tecgraf could use whatever nomenclature fancies them), where

alfa 1...alfa N implies product still in development, specifications still
subject to change, conceptual and implementation bugs expected and accepted,
documentation scarce or not available.

beta 1...beta N implies product in debug phase, specifications frozen,
implementation bugs expected and accepted, documentation in draft phase.

rc 1...rc N implies product in final debug phase, specifications frozen, no
known implementation bugs, documentation in revision phase.

gold implies product ready for public delivery, no known implementation
bugs, documentation ready.

As the versioning numbers I think we could adopt the usual
Major.Minor.BugFix notation, where

Major implies conceptual and significant changes in the language
specification
Minor implies corrections, improvements and small changes in the language
specification
BugFix implies only patches and bug fixes. No changes the language in
specification.

Regards,

Carregal

> -----Original Message-----
> From: owner-lua-l@tecgraf.puc-rio.br
> [mailto:owner-lua-l@tecgraf.puc-rio.br]On Behalf Of John Belmonte
> Sent: Saturday, June 15, 2002 2:53 AM
> To: Multiple recipients of list
> Subject: release methodology
>
>
> A request to the Lua authors: please give some attention to
> your release
> methodology.  I don't have any ideal in mind, but suggest you take a
> look at how things are done with popular projects that have survived
> many years of growing pains such as gcc, Python, and Mozilla.
>
> The main gripe I have is with release naming (including both
> "official"
> and "work" releases, as you call them).  For example recently
> an update
> to 4.0 was made, called "4.0-update".  What will happen if
> there needs
> to be an update to the update?  This also causes problems for
> downstream
> packagers, as evident by the version on Daniel's Debian package:
>
>      lua40 (4.0-5) unstable; urgency=medium
>
>        * Applied the Lua 4.0 official patchset
>        * ...
>
> When I see this I know something is wrong immediately, because the
> number after the dash is supposed to represent the patch level for
> converting the upstream package into Debian-land.  Any changes by the
> upstream authors should be represented in the number before the dash.
> (Perhaps Daniel should have versioned it as "4.0update-1", but my
> intended point is that you should have given the new release
> a name such
> as 4.0.1.)
>
> Another release naming problem is the arbitrary jump in calling
> development releases 4.1work and then 5.0work.  Deciding that
> the next
> official release would be 5.0 was not a good reason to change
> the naming
> in this work series.  It has only created confusion, and made
> it harder
> to search the archive for development since 4.0.
>
> Regards,
> -John
>
>
>
> --
> OpenPGP encrypted mail welcome.
>