On Tue, Apr 30, 2002 at 12:26:42AM +0200, Andreas Oesterhelt wrote:
> > Don't you think you are making some kind of naming confusion, and naming alpha
> > a beta version, and beta a rc version ?
> >
> > alpha -> The code is incomplete, unstable and buggy
> > beta -> The code is complete, unstable and buggy
> > rc -> The code is complete, stable and buggy
> > release -> The code is complete, stable and bug free (yeah, sure)
> Ooops, I wasn't aware that this is somehow standardized. What does
> "incomplete" mean?
This is not a standard, but ratter a convention. There is another,
that is even more fiercy. Something like:
alpha: 50% of the code done (functionality)
beta: 100% of the code code (functionality) QA takes over here
pre-release: early release of the final version (AKA public beta)
> Not everything there that would be required for
> successful building or running? Or just that some parts of a bigger
> design are only implemented by dummy routines yet? The latter might
> actually happen in 3.1.
Incomplete in regard the project design regarding functionality.
> Anyway, I would like to see high-risk
> development-branch packages marked somehow more obviously than through
> an odd minor, so that people won't point their fingers at us when things
> break horribly. If "alpha" is not the correct way, what can we use to
> denote "Code is maybe incomplete, unstable and may contain really
> bad bugs"?
I think an alpha version should never be avaliable ouside cvs. Okey, this
is agains the "release early, release often" concept, but we will be
releasing it, but only on cvs. On the site, we release the beta version
and release-canditate versions.
Lets take the moment to make one further standarization.
X.Y.Z
Y = odd -> development
Y = even -> stable
Z = odd -> SF release
Z = even -> CVS release
Further yet:
Z = 10 -> first beta release on SF
Z = 90 -> first pre-release
What do you think ? I also want to avoid things like X.Y.Z-rc1.
> > > BTW: I noticed that the whole version substitution, not just
> > > the RPM release number has gone from the RPM targets.
> > > Shouldn't we be substituting the software version in the
> > > specfiles? (And use your RPM_PACKAGEV as you do for naming
> > > the package file).
> > Nope. Lets have the makefile touching the specfiles as little as possible.
> > Lets wait to have all that unified version and specfiles stuff for after 3.0.
> I agree that we shouldn't be spending much work on this now and
> wait for a thorough clean up in 3.1. The current state still seems
> a little dangerous to me, because the RPM targets in the Makefile
> don't warn about the need to set the version manually. Could we
> either have the version mangling (maybe plus using RPM_PAGAGEV as
> "Release: ") back, or fill these fields with dummy values like
> "FILL ME PLEASE!" and let make check for them (and fail if present)?
Nope. A packager should take notice of it, and will see, even if only
when the package is built.
> I would just like to avoid that someone calls a release target and gets
> a nice-looking RPM in return, which has wrong version info internally.
Trust me. A packager always know what version (s)he is building. On that
regard, I trust packagers.
> I could do either of the above, but would like your opinion first.
I don't think that is good. That would be to intrusive. In any case, I
think I have an idea. What about if rpm would check for the version
on the code, and then on the specfile. If they do not match, abort the
build process ? I could implement it easily.
[]s
>
> Best regards,
> --Andreas
>
--
Rodrigo Barbosa - rodrigob at tisbrasil.com.br
TIS - Belo Horizonte, MG, Brazil
"Quis custodiet ipsos custodes?" - http://www.tisbrasil.com.br/
Brainbench Certified -> Transcript ID #3332104
|