I know, you said (as I do) the jar-per-filesystem is the clean solution to go, but you also pointed out (as I do too ;-) ) the amount of work for each voter then.
Sorry, but are you guys seriously saying that the "work for each voter" is too much? In the end this means "No, we cannot do 'release early, release often' - too much work for the voters" ...for the *voters*? Come on guys!! I have the same "issue" with jci then. But I think the modules do not require to be a full-blown release of the core. (documentation, etc) ...they are modules and not to be used outside of the core. So the burden I see is to actually to prepare the releases. But I have my script that pretty much does a release with a few command lines. (helps to have gpg-agent running) release checksum release checksum-verify release sign release sign-verify release stage release stage-verify Then send out a mail to have people check the RC on people.apache.org. After the voting I tag the release and do release live release live-verify release download Everyone is wining about our huge release procedure - but it's only a lot to do if you do all this by hand. (Why would you want to do that?) My script is pretty stupid and would probably need to be adjusted to work for all different projects ...but hell - I don't fear making releases now anymore. So should no one else. So let's do what makes most sense - not what seems less work. My 2 cents cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
