On Wed, 2 Mar 2005 14:49:41 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled: (B (B> On Wednesday, 02 March 2005, at 11:43:09 (+0900), (B> Carsten Haitzler wrote: (B> (B> > because of this: (B> > (B> > asapagus.sh: (B> > <<<snip>>> (B> (B> I'm sure that's great for you, but you're not the only one dealing (B> with these packages. (B> (B> If you're already updating configure.in, you should update the spec (B> files at the same time. And all the other packaging files. It's no (B> more difficult than what you've already done. (B (Bi just moved eet to auto-generate everything. rpm's build. debs should and oe/bb (Bpackages should build too. it uses the master version info in configure.in (B (B> > i did - i said it helps making snapshots without having to fiddle (B> > the main version and play with libtool versioning info (B> > etc. etc. etc. etc. (B> (B> For you, and only you. (B (Bno - for many others too. it means now that a packages version is consistent (Bwith a source snapshot. (B (B> > it makes automated releases that have a CONSISTENT VERSIONING SCHEME simple. (B> (B> See above. (B (Bsee above. (B (B> > yes it is. see above. it IS an integer. (B> (B> "001" is an integer. ".001" is not. (B (Bif we are arguing over the that. then every version is not a number as it has (Bmultiple "dots" why not just call the version "shksda_sew.eew" ? the fact is (Bbefore there was an inconsistent extension to the version scheme (x.y.z) and now (Bi made it consistent (x.y.z.v) and moved that consistency across a large chunk (Bof EFL. now versions can be consistently compared between source snaps AND (Bpackages ALL you need to do is EXACTLY what u did before - go and edit the (Bversion field in the .spec - it has not changed WHAT you have to do. not 1 iota (Bin principle. if i go changing versions of nay package u need to update the (B.spec. i have done this many times in the past and not once was there any (Bcomplaint like this - not once "ooh you changed the version number. we need to (Bhave a meeting about changing version numbers". it never happened in the past. (Bwhy this time? what is so offensive about an extra version number (that rpm (Bhandles just fine btw). in order to make it easier to provide snapshots and (Breduce the overhead of answering support mails about "my autofoo version X (Bdoesnt work with Y Z etc." ? (B (B> > see above - again. it means the SAME rule can be applied to ALL (B> > packages - no exceptions. for those close to a 1.0.0 we can keep (B> > them at 0.9.9 or 0.16.999 for example - we can up the real version (B> > as we please with automated releases incrementing the release. for (B> > somone who does rpm packaging you seem to have instantly forgotten (B> > the release number in packages (-1, -2, -3 etc.) the moment u look (B> > at src. the .001 is the exact equivalent to it - but on the source (B> > side. (B> (B> You are not making changes to all packages at once. Thus you have (B> created a situation where there may be a "release" of a particular (B> package in which nothing whatsoever has changed from the previous (B> "release." I don't see this as a good thing, and it's no better than (B> CVS snapshots. (B (Bif u read the script. u will notice my ~/s/asparagus can release an increment (Bjust 1 package alone. m y master script that just goes over everything does (Beverything in the list i give it. (B (Band its much better than cvs snaps. cvs snaps are just cvs checked out and (Btarred. people still need to have autofoo to build them. release tarballs do not (Bneed this. (B (B> While saving yourself some work, you've created a metric fuck-ton of (B> work for those of us doing packaging. What you *should* do, IMHO, is (B> put someone in charge of Release Management. If one or more packages (B> are at a stable point for a release of some type, let the release (B> manager worry about version number changes and such. (B (Bdude - i've asked before to have a release manager. no one has stepped forward (Band stayed there. there's people making packages for disparate systems and (Bpackaging schemes, but no release manager. i have given up asking as all i do is (Bwait for someone to step up and do it and end up getting impatient and doing it (Banyway. (B (B> These are separate packages. Not everything should be released all at (B> once, particularly when nothing has changed from the last release. (B> Trying to treat them all as one big unit defeats the purpose of having (B> things split out into libraries. (B (Bagreed - amazingly thats why i have a script that can make a release of just 1 (Bof them at a time. i also have one that can just do all of it. (B (B> Furthermore, adding .NNN to the end doesn't create a versioning scheme (B> that's any more or less consistent than before (except for the 3 (B> packages erroneously using _preXX). The only thing it accomplishes is (B> tagging everything with the same suffix, and by using the same suffix (B> for disparate packages, you've rendered it completely useless. No (B> useful information is gained from .001 or .002 other than that .002 is (B> a bigger number. Anything or nothing may have changed for any (B> particular package, and the unsuspecting user is forced to download (B> them ALL again even though there may be no difference whatsoever. (B (B> MAJOR.MINOR.PATCHLEVEL is a perfectly reasonable scheme, and when done (B (Bthe problem is we already are overloading the patchlevel and we just need (Banother minor level below that. i plan on removing the .NNN once things go gold. (Bbut for things like E17 that is 0.16.999, ecore 0.9.9 and evas 0.9.9 is getting (Ba bit silly - so i'm putting a "disposable" extra version at the end. (B (B> properly it provides useful information regarding which packages have (B> changed and which have not. I can certainly understand what a pain it (B> can be to manage 18 different packages on your own, but the solution (B> is not to make it easier for you while making it harder for everyone (B> else. The solution is to stop making it a one-man show when it's (B> not. Put a release manager (shadoi? dj2? digitalfallout?) in charge (B> of the packages you "own," and let the maintainers of other packages (B> (RbdPngn for EWL, HandyAndE for engage, xcomp/atmos for entrance, (B> etc.) do their own releases. (B (Bas i said. i had ASKED ages ago. dig thru the archives. (B (B> And brainstorm things before you take unilateral action, at least when (B> it comes to packaging and such. There's a chance somebody might have (B> a different/better/cleaner idea. (B (Bi'm not sure whats hard or unclean about the .NNN - beyond offending your (Bsensibilities. it lets users see that the version is indeed a snapshot release (Bnumber, not a version update. it is numeric. it works in packging systems. no (Bone has complained before about version updates. (B (Byou know how it works. you ask someone to do something, someone might say "yes (Bme" they do it for 3 months, then vanish. the developers already have enough to (Bdo without becoming release maintainers. in the end any release manager will end (Bup doing something like this to make their lives easier - automating it. if (Banything i've gone and made their lives easier if someone wants to be in charge (Bof such things. (B (Bnow back to something productive... i've gone and made eet fully (Bauto-releasable. .spec, debian package versions etc. etc. etc. i have built rpm (Band debian packages (as per the README) right now and they build find with the (Bcorrect versions. see the README. packagers need to do nothing more than execute (Bthose commands after getting a source tarball snap. (B (Bnow if THAT is now a fuck-tonne more work than u currently have... you have a (Bstrange idea of more work :) its as close to zero work as possible as i can see (B(beyond adding make rules to run the rpm and deb packaging commands for you - ie (Bmake rpm, make deb etc.) (B (B-- (B------------- Codito, ergo sum - "I code, therefore I am" -------------- (BThe Rasterman (Carsten Haitzler) [EMAIL PROTECTED] $BMg9%B?(B [EMAIL PROTECTED] (BTokyo, Japan ($BEl5~(B $BF|K\(B) (B (B (B------------------------------------------------------- (BSF email is sponsored by - The IT Product Guide (BRead honest & candid reviews on hundreds of IT Products from real users. (BDiscover which products truly live up to the hype. Start reading now. (Bhttp://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click (B_______________________________________________ (Benlightenment-devel mailing list ([email protected] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
