On Wednesday, 02 March 2005, at 11:43:09 (+0900), Carsten Haitzler wrote: > because of this: > > asapagus.sh: > <<<snip>>>
I'm sure that's great for you, but you're not the only one dealing with these packages. If you're already updating configure.in, you should update the spec files at the same time. And all the other packaging files. It's no more difficult than what you've already done. > i did - i said it helps making snapshots without having to fiddle > the main version and play with libtool versioning info > etc. etc. etc. etc. For you, and only you. > it makes automated releases that have a CONSISTENT VERSIONING SCHEME simple. See above. > yes it is. see above. it IS an integer. "001" is an integer. ".001" is not. > see above - again. it means the SAME rule can be applied to ALL > packages - no exceptions. for those close to a 1.0.0 we can keep > them at 0.9.9 or 0.16.999 for example - we can up the real version > as we please with automated releases incrementing the release. for > somone who does rpm packaging you seem to have instantly forgotten > the release number in packages (-1, -2, -3 etc.) the moment u look > at src. the .001 is the exact equivalent to it - but on the source > side. 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. 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. 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. 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. 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. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "I've been looking for a Savior in these dirty streets, Looking for a Savior beneath these dirty sheets." -- Tori Amos, "Crucify" ------------------------------------------------------- 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
