Michael Jennings <[EMAIL PROTECTED]> [2005-03-02 14:49]:
> You are not making changes to all packages at once.  Thus you have
> created a situation where there may be a "release" of a particular
> package in which nothing whatsoever has changed from the previous
> "release."  I don't see this as a good thing, and it's no better than
> CVS snapshots.

ACK.

> While saving yourself some work, you've created a metric fuck-ton of
> work for those of us doing packaging.  What you *should* do, IMHO, is
> put someone in charge of Release Management.  If one or more packages
> are at a stable point for a release of some type, let the release
> manager worry about version number changes and such.
> 
> These are separate packages.  Not everything should be released all at
> once, particularly when nothing has changed from the last release.
> Trying to treat them all as one big unit defeats the purpose of having
> things split out into libraries.

ACK.

> Furthermore, adding .NNN to the end doesn't create a versioning scheme
> that's any more or less consistent than before (except for the 3
> packages erroneously using _preXX).  The only thing it accomplishes is
> tagging everything with the same suffix, and by using the same suffix
> for disparate packages, you've rendered it completely useless.  No
> useful information is gained from .001 or .002 other than that .002 is
> a bigger number.  Anything or nothing may have changed for any
> particular package, and the unsuspecting user is forced to download
> them ALL again even though there may be no difference whatsoever.

ACK.

> MAJOR.MINOR.PATCHLEVEL is a perfectly reasonable scheme, and when done
> properly it provides useful information regarding which packages have
> changed and which have not.  I can certainly understand what a pain it
> can be to manage 18 different packages on your own, but the solution
> is not to make it easier for you while making it harder for everyone
> else.  The solution is to stop making it a one-man show when it's
> not.  Put a release manager (shadoi?  dj2?  digitalfallout?) in charge
> of the packages you "own," and let the maintainers of other packages
> (RbdPngn for EWL, HandyAndE for engage, xcomp/atmos for entrance,
> etc.) do their own releases.

ACK. I'll happily help out.

> And brainstorm things before you take unilateral action, at least when
> it comes to packaging and such.  There's a chance somebody might have
> a different/better/cleaner idea.

ACK.

-- 
Regards,
Tilman


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to