Hi all guys, for the CLI improvements please follow up the discussion on https://issues.apache.org/jira/browse/ANY23-71
Unfortunately there has been too much sun during the Weekend to stay at home programming, I took advantage to take outside the puppy so that patch is the only one I had the chance to take care. More incoming during the week! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Mar 30, 2012 at 4:28 PM, Simone Tripodi <[email protected]> wrote: > Hello!!! > >> This isn't the only release - indeed, some would say that that being too >> perfect discourages others getting involved as the barrier to contribution >> is higher. >> > > sure of course, that makes me reconsider a couple of points... > >> So I suggest setting a timescale with hard date for the code freeze. >> > > yup agreed, at least we won't postpone to the infinity :) > >> If something gets done, great, if it doesn't, shrug. There will be another >> release coming along. First release may go through easily, it may cause >> comment - focus on process this time. Once that is bedded down in the >> project, it's easy to release but first release is about the process. >> > > I should have almost the whole weekend available, I'll take care about > any23 as much as I can :P > >> >> I don't know how much you've discussed this already - I haven't been able to >> follow everything recently ... >> >> In Jena, we have got this down to three steps: >> >> mvn release:clean release:prepare -Papache-release >> mvn release:perform -Papache-release >> >> then run >> >> <shell script that builds the dist/ area> >> >> mvn puts everything into staging (yukness => you get .asc.md5, .asc.sha1 -- >> everyone finds this and eventually just lives with it as a fact of life). >> > > yup this is what I actually do in commons, cocoon, ..., and already > prepared in any23 (apache-release profile will be enabled > automatically when releasing) but I really wanted to avoid a 2-step > process - anyway I already asked my mvn fellows and looks like there's > no escape to this "trap" :( I'll continue deploying source/binary > releas bundles manually. > > Release bundles in Any23 are created via the assembly-plugin (ehm, > sources are still missing *blush*) I'll take care of reviewing during > the WE. Anyway, 2 (or more) pair of eyes more to review the done work > will be much more than appreciated and welcome :) > > All the best and thanks a lot for your inputs, have a nice day! > > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Fri, Mar 30, 2012 at 12:38 PM, Andy Seaborne <[email protected]> wrote: >> On 30/03/12 09:22, Simone Tripodi wrote: >>> Hi Lewis, >>> >>> there are just few minor additions I'd like to discuss before to start >>> cutting an RC: >>> >>> 1 update the plugin page according to the ServiceLoader pattern we >>> adopted; >>> 2 improving the CLI code - we can do a little better maintainable >>> code, switching to JCommander[1] pattern >>> 3 add a maven archetype to simplify plugins development >> >> This isn't the only release - indeed, some would say that that being too >> perfect discourages others getting involved as the barrier to contribution >> is higher. >> >> So I suggest setting a timescale with hard date for the code freeze. >> >> If something gets done, great, if it doesn't, shrug. There will be another >> release coming along. First release may go through easily, it may cause >> comment - focus on process this time. Once that is bedded down in the >> project, it's easy to release but first release is about the process. >> >> Sometimes, I think a podling should do the release thing, then throw it >> away. At least that way, it's clear the release is much more about Apache >> process than a normal release. >> >> High ceremony ... with people watching. >> >> >>> 4 understand how to concurrently deploy mvn artifacts on nexus and >>> binaries bundles (included asc signs and md5/sha1 checksums) on the >>> builds server, in one shot (I would avoid the RC manager has to >>> perform manual operations as much as I can) >> >> I don't know how much you've discussed this already - I haven't been able to >> follow everything recently ... >> >> In Jena, we have got this down to three steps: >> >> mvn release:clean release:prepare -Papache-release >> mvn release:perform -Papache-release >> >> then run >> >> <shell script that builds the dist/ area> >> >> mvn puts everything into staging (yukness => you get .asc.md5, .asc.sha1 -- >> everyone finds this and eventually just lives with it as a fact of life). >> >> This also creates the "source-release.zip" item which is the thing that is >> *the* release. Strictly, that's what the vote is about. All the other stuff >> is not "the release". It just the stuff people use! >> >> The shell script picks bytes out of the local machine maven repository. >> That does not include .md5/.sha1. >> >> In fact, we now recalculate those rather than go pull them back from Nexus >> staging. maven creates .md5 with just the md5 has in the file. md5sum(1) >> puts the file name in and then "md5sum -c *.md5" works. >> >> Some other projects have different processes - some have good write ups. >> See "sling" and "rave" for examples. "rave" has a 130 line shell script >> that does everything - but for this first release, it might be easier to be >> a bit more manual because it means you get the knowledge to capture in a >> script. >> >> >>> while 3 and 4 are minor, I see 1 and 2 more important - it will define >>> the *Apache* Any23 design and the thousands (hopefully :P) of users >>> that start develop their tools on top of Any23, will do in a way that >>> will be backward/forward compatible. >>> >>> WDYT? >> >> 1, 2 and 3 are technical. >> >> 4 is major. >> >> I went checking ... >> >> The build is in a good state and most of the N&L files look OK (I didn't see >> if the N&L files inside a jar were right - I didn't see a combined >> redistribution N&L in the with-deps jar though). >> >> The RAT report is quite good - most unlicensed files are test materials (yet >> another area for "debate" on g@i). >> >> Andy >> >> (( >> My experience: the first Jena release took a while to set up the N&L files, >> but votes on -dev and g@i were straight forward. The first TDB release got >> a somewhat detailed analysis on g@i and provoked some discussion about what >> actually is correct and required practice. It's all-meant but wearing a >> flame retardant jacket is advised. >> >> And the Nexus buttons in staging are very close together. "Release" and >> "Drop" are rather different actions but right next to each other :-) >> )) >> >> >> >>> I'll dedicate the coming WE to Any23 to start arranging things. >>> >>> Have a nice day, all the best! >>> -Simo >>> >>> [1] http://jcommander.org/ >>> >>> http://people.apache.org/~simonetripodi/ >>> http://simonetripodi.livejournal.com/ >>> http://twitter.com/simonetripodi >>> http://www.99soft.org/ >>> >>> >>> >>> On Thu, Mar 29, 2012 at 6:22 PM, Lewis John Mcgibbney >>> <[email protected]> wrote: >>>> Hi Everyone, >>>> >>>> The final remaining 0.7.0 issue which I created is certainly not a >>>> blocker, >>>> and can wait until a later date to be addressed as I don't have time this >>>> week. >>>> >>>> Are we ready to blow a 0.7.0-incubating RC? >>>> >>>> Here's to hoping :) >>>> >>>> Thanks >>>> >>>> Lewis >>>> >>>> -- >>>> *Lewis* >>
