On 2 March 2010 17:44, David Jencks <[email protected]> wrote: > I think everything is ok.... I think (at least with dryRun=true) that the > release plugin builds the project first as-is and checks that signing etc > works. > > I added autoVersionSubmodules=true in the root parent pom which will make > things work more smoothly :-)
If that means the maven-release-plugin won't ask what version number to use for the child modules of the one being released then this is good and just what we want for most modules. I think we might need to do something special with the modules representing the blog sample bundles (as Joe mentions in another email). > > I really recommend changing the version to 0.1-incubating-SNAPSHOT first, > I'm happy to do this if you want. I agree, that would give the maven-bundle-plugin less to do and one less moving part would be fine with me. Thanks. > > > thanks > david jencks > > On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote: > >> scratch that. I'm working thru this: >> http://maven.apache.org/developers/release/apache-release.html as >> there's several steps I haven't done. >> >> On 2 March 2010 16:17, Jeremy Hughes <[email protected]> wrote: >>> >>> On 2 March 2010 02:28, David Jencks <[email protected]> wrote: >>>> >>>> I've done most of what I think is needed for aries to be basically >>>> releasable. There are some bits left and possibly stuff I've missed. >>>> >>>> 1. legal file review. There are a bunch of NOTICE files that claim that >>>> work from osgi is included. Really? license and notice files are >>>> supposed >>>> to apply to what is actually in an artifact or checkout. Are some of >>>> our >>>> source files copied from an osgi source? Also all the legal files that >>>> end >>>> up in binary artifacts need to be checked. Also we need to run the rat >>>> plugin: this should be configured in the default pom. Not sure if I >>>> will >>>> get to this. >>>> >>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how to >>>> make >>>> sure that an eba is working so I didn't mess with this. I think the >>>> plugin >>>> itself is working well enough to use though. >>>> >>>> 2. ordering dependencies and dependency management. I find it >>>> convenient to >>>> have these alphabetized so I can find what I'm looking for, but I >>>> haven't >>>> done this in most poms. I'm not sure why there isn't a usable tool for >>>> doing this but I haven't found one. Dull but useful... >>>> >>>> 3. It would probably be a really good idea to run mvn dependency:analyze >>>> and >>>> look carefully at the results. The results from this can require >>>> interpretation so its best if someone who is very familiar with how the >>>> code >>>> works does this. >>>> >>>> 4. before a release all snapshots need to be resolved to released >>>> versions. >>>> I don't know if there are any snapshots. >>>> >>>> To summarize what I've tried to do: >>>> >>>> 1. default-parent has dependency management for the basic osgi >>>> dependencies >>>> that all projects are pretty sure to use including the pax stuff used >>>> mostly >>>> for testing. >>>> >>>> 2. each subproject has legal files in its checkout root >>>> >>>> 3. each subproject has an scm element in its pom, but no others do. >>>> >>>> 4. each subproject has dependency management for everything included in >>>> it. >>>> In addition, it has its subprojects listed in dependency management. >>>> (this >>>> is bent slightly for the samples). This means that >>>> (a) modules in a subproject don't need to include versions for use of >>>> other >>>> modules >>>> (b) you can get dependency management for all the modules in a >>>> subproject >>>> by depending on the subproject pom with scope import. (see the samples >>>> pom >>>> for an example). >>>> >>>> 5. As a result of (4), modules don't have any versions in any dependency >>>> elements. >>>> >>>> Release is going to involve... >>>> >>>> releasing the parent >>> >>> In trunk/parent I tried: >>> >>> mvn -DdryRun=true release:prepare -Papache-release >>> >>> Providing 0.1-incubating for the release version >>> Defaulting to parent-0.1-incubating for the SCM release tag >>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version >>> >>> then when it builds the 'Top Parent POM' it outputs this: >>> >>> [INFO] [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] [INFO] Building Aries :: Top Parent POM >>> [INFO] [INFO] task-segment: [clean, verify] >>> [INFO] [INFO] >>> ------------------------------------------------------------------------ >>> [INFO] [INFO] [clean:clean] >>> [INFO] [INFO] Setting property: classpath.resource.loader.class => >>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. >>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'. >>> [INFO] [INFO] Setting property: resource.loader => 'classpath'. >>> [INFO] [INFO] Setting property: resource.manager.logwhenfound => 'false'. >>> [INFO] [INFO] [remote-resources:process {execution: default}] >>> [INFO] [INFO] [site:attach-descriptor] >>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}] >>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping >>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, >>> skipping >>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, >>> skipping >>> [INFO] [INFO] Building zip: >>> >>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip >>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping >>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, >>> skipping >>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, >>> skipping >>> [INFO] [INFO] Preparing source:jar >>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent >>> recursive invocation. >>> [INFO] [INFO] No goals needed for project - skipping >>> [INFO] [INFO] [source:jar {execution: attach-sources}] >>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}] >>> [INFO] [INFO] Not executing Javadoc as the project is not a Java >>> classpath-capable package >>> [INFO] [INFO] [gpg:sign {execution: default}] >>> >>> so it seems to be outputting 1.0.0 artifacts still. Any ideas? >>> >>> Then stops at the gpg stage. I thought it would prompt me for my key >>> passphrase at this point. Do I need gpg-agent to be running? >>> >>>> updating the parent version wherever it is used (all subproject parents) >>>> >>>> releasing the subprojects in an appropriate order and updating their >>>> versions wherever they are used. >>>> >>>> It might be worthwhile changing the pom version to >>>> 0.1-incubating-SNAPSHOT >>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this >>>> because >>>> then the versions plugin can be used to update use of a subproject to >>>> the >>>> newly released version of what it uses. Going from >>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this. >>>> >>>> As noted in the "root" pom, don't try to release the root pom and don't >>>> try >>>> release everything at once from the root pom. >>>> >>>> thanks >>>> david jencks >>>> >>>> >>>> >>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote: >>>> >>>>> I started looking into cleaning up the build, and of course it is >>>>> taking >>>>> longer than I expected. >>>>> >>>>> I'm seriously hampered by failing tests in a fresh checkout. >>>>> >>>>> There are some projects in application that stop compiling if you >>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are >>>>> getting on >>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to >>>>> the >>>>> dependencies seems to fix it if you can figure out where the out of >>>>> date >>>>> jars are coming from. >>>>> >>>>> The build is already much closer to a multi-release model than a single >>>>> release model. >>>>> >>>>> I've diffed what I have so far and attached it to ARIES-173. It >>>>> includes >>>>> scm info and a lot of version corrections. Due to the failing tests >>>>> I'm not >>>>> too comfortable committing it. >>>>> >>>>> Is anyone else seeing test failures locally? >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> It 'd be great if you are willing to fix these build issues, since you >>>>>> just went through a big release in Geronimo. :) >>>>>> >>>>>> I know the maven release plugin isn't friendly to use some cases, so >>>>>> it is best we get these resolved to make our release process a bit >>>>>> easier. >>>>>> >>>>>> EBA plugin would be a very nice add-on, if it comes in time with the >>>>>> release. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Lin >>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>>> I would like to understand the problems you see better, but I do not >>>>>>>> have >>>>>>>> the maven background you guys have, any chance you could explain >>>>>>>> what >>>>>>>> the >>>>>>>> problems are, why they are problems and the solution at some point? >>>>>>> >>>>>>> The biggest immediate problem is that without correct svn info you >>>>>>> can't >>>>>>> do >>>>>>> a release with the release plugin. I'm pretty sure the way its set >>>>>>> up >>>>>>> now, >>>>>>> when you try, the tag will be under maven's apache pom, not aries. >>>>>>> (you'll >>>>>>> fail unless you happen to be a maven committer too). You definitely >>>>>>> don't >>>>>>> want to try to do a release without the release plugin. >>>>>>> >>>>>>> Organizationally there's no way that for instance blueprint, >>>>>>> application, >>>>>>> and samples should always be released in synchrony. Any time two of >>>>>>> them >>>>>>> happen to be ready for release at the same time it will be purely >>>>>>> accidental. Right now everyone wants to get a milestone out the >>>>>>> door, >>>>>>> but >>>>>>> looking at the different projects their state of completion is pretty >>>>>>> much >>>>>>> wildly different. A decision to release all of them at once is not >>>>>>> based in >>>>>>> any way on them being equally complete. I'm suggesting that since >>>>>>> build >>>>>>> fixes are needed anyway, why not set up a maintainable structure that >>>>>>> will >>>>>>> continue to work beyond this publicity release. The benefit to users >>>>>>> is >>>>>>> that aries will be able to release bits in a timely fashion; >>>>>>> otherwise >>>>>>> the >>>>>>> entire project will never be in a releasable state at once. (I'm only >>>>>>> exaggerating a little bit :-) >>>>>>> >>>>>>> What got me looking at this at all is what look like wild gyrations >>>>>>> that >>>>>>> don't really use maven properly to get an .eba (or some artifact) out >>>>>>> the >>>>>>> door. This might be ok for one release but (a) I think this can be >>>>>>> done >>>>>>> directly with the assembly plugin short term and (b) an >>>>>>> eba-maven-plugin >>>>>>> seems like the obvious more long term solution. >>>>>>> >>>>>>> I'm willing to fix the build and probably work on an eba plugin, but >>>>>>> want to >>>>>>> be sure this is ok with everyone first. >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Alasdair >>>>>>>> >>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This discussion got me worried enough to take a look at the aries >>>>>>>>> build. >>>>>>>>> Now I'm even more worried. >>>>>>>>> >>>>>>>>> While it might feel good to try to push out a release as fast as >>>>>>>>> possible >>>>>>>>> I'd prefer to see a sustainable build system in place first. So >>>>>>>>> far >>>>>>>>> it >>>>>>>>> looks to me as if aries is going to be a bunch of loosely coupled >>>>>>>>> subprojects. Building them all at once is not going to work for >>>>>>>>> long. >>>>>>>>> I >>>>>>>>> think we should recognize that and put that in the build system >>>>>>>>> now. >>>>>>>>> To me >>>>>>>>> this means: >>>>>>>>> >>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk. >>>>>>>>> 2. each subproject has pom info sufficient so it can be released >>>>>>>>> (mostly >>>>>>>>> svn info) (right now this is completely missing everywhere as far >>>>>>>>> as >>>>>>>>> I can >>>>>>>>> see, which will result in ares getting tagged into svn as part of >>>>>>>>> the >>>>>>>>> apache >>>>>>>>> pom) >>>>>>>>> >>>>>>>>> We can still have a "fake" pom that builds everything, but it won't >>>>>>>>> be >>>>>>>>> part of any release procedure. >>>>>>>>> >>>>>>>>> Having separately released subprojects does not prevent having a >>>>>>>>> single >>>>>>>>> vote on all the releases. >>>>>>>>> >>>>>>>>> I'd suggest a few other pom tweaks such as using resources and >>>>>>>>> filtered-resources to distinguish when filtering is called for. >>>>>>>>> >>>>>>>>> In addition relevant to this particular bit of the thread, we need >>>>>>>>> an >>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first >>>>>>>>> release >>>>>>>>> would >>>>>>>>> be a great idea IMO. >>>>>>>>> >>>>>>>>> If there's general agreement I can spend some time playing with the >>>>>>>>> build >>>>>>>>> and possibly working on the eba plugin. >>>>>>>>> >>>>>>>>> thoughts? >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> david jencks >>>>>>>>> >>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote: >>>>>>>>> >>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>> >>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I'd also like to see us release the sample applications but I >>>>>>>>>>>> think >>>>>>>>>>>> there is >>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader >>>>>>>>>>>> generate >>>>>>>>>>>> EBAs >>>>>>>>>>>> using different techniques - but both leverage the >>>>>>>>>>>> maven-antrun-plugin >>>>>>>>>>>> to >>>>>>>>>>>> finally produce a file of type "eba". >>>>>>>>>>> >>>>>>>>>>> I realised the .eba file generated in the blog-assembly module >>>>>>>>>>> wasn't >>>>>>>>>>> being pushed into my local repo. I've made some changes to the >>>>>>>>>>> pom.xml >>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the >>>>>>>>>>> .eba >>>>>>>>>>> artifact and the build-helper-maven-plugin to push the artifact >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba >>>>>>>>>>> for >>>>>>>>>>> the ianal plugin in the verify phase to succeed. >>>>>>>>>> >>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you know >>>>>>>>>> if >>>>>>>>>> it >>>>>>>>>> will work with the maven-release-plugin to push the eba artifacts >>>>>>>>>> when we do >>>>>>>>>> a release? If so, then I should look at using the same mechanism >>>>>>>>>> for >>>>>>>>>> AriesTrader. >>>>>>>>>> >>>>>>>>>>>> I think the result is that the eba will not be available in a >>>>>>>>>>>> maven >>>>>>>>>>>> repository. >>>>>>>>>>>> >>>>>>>>>>>> One of the differences is that AriesTrader first generates a jar >>>>>>>>>>>> using >>>>>>>>>>>> the >>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar >>>>>>>>>>>> will >>>>>>>>>>>> be >>>>>>>>>>>> managed by maven and IIUC it should be deployable as an >>>>>>>>>>>> "application" >>>>>>>>>>>> even >>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is >>>>>>>>>>>> correct >>>>>>>>>>>> then >>>>>>>>>>>> perhaps delivery of an application jar is an acceptable approach >>>>>>>>>>>> for >>>>>>>>>>>> the 1st >>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox >>>>>>>>>>>> assembly >>>>>>>>>>>> to >>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual >>>>>>>>>>>> bundles. >>>>>>>>>>> >>>>>>>>>>> Using the maven-assembly-plugin likely the preferred approach >>>>>>>>>>> long >>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the >>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven >>>>>>>>>>> control and add the .eba one? >>>>>>>>>> >>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work out - >>>>>>>>>> is >>>>>>>>>> there anything wrong with the approach I mentioned earlier of just >>>>>>>>>> using the >>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current >>>>>>>>>> application >>>>>>>>>> support only look at *.eba archives? >>>>>>>>>> >>>>>>>>>>>> Joe >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Guillaume Nodet wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I'd like to see at least those included: >>>>>>>>>>>>> * blueprint >>>>>>>>>>>>> * jmx >>>>>>>>>>>>> * jndi >>>>>>>>>>>>> * transaction >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think applications are really usable yet and I haven't >>>>>>>>>>>>> really >>>>>>>>>>>>> looked at JPA yet, so can't tell about it. >>>>>>>>>>>>> The transaction component is functional and we've been using it >>>>>>>>>>>>> mostly >>>>>>>>>>>>> unchanged since a long time in ServiceMix. >>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking >>>>>>>>>>>>> about >>>>>>>>>>>>> declarative transactions for blueprint, note). >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for >>>>>>>>>>>>>> volunteering >>>>>>>>>>>>>> to be the release manager. Your response helps me get a >>>>>>>>>>>>>> better >>>>>>>>>>>>>> picture >>>>>>>>>>>>>> of >>>>>>>>>>>>>> the plans. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was really just interested in the general objectives and >>>>>>>>>>>>>> timing >>>>>>>>>>>>>> since >>>>>>>>>>>>>> it >>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb >>>>>>>>>>>>>> means >>>>>>>>>>>>>> it >>>>>>>>>>>>>> will >>>>>>>>>>>>>> be >>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little >>>>>>>>>>>>>> too >>>>>>>>>>>>>> steep to >>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The more communication the better. It's important to get >>>>>>>>>>>>>> everybody >>>>>>>>>>>>>> thinking >>>>>>>>>>>>>> and planning along the same lines (or understand quickly if >>>>>>>>>>>>>> there >>>>>>>>>>>>>> are any >>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of >>>>>>>>>>>>>> creating >>>>>>>>>>>>>> a >>>>>>>>>>>>>> release candidate next week means that we should be getting >>>>>>>>>>>>>> more >>>>>>>>>>>>>> restrictive >>>>>>>>>>>>>> on new content to avoid any unpleasant surprises. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't have any strong opinions on what should be in or out - >>>>>>>>>>>>>> but >>>>>>>>>>>>>> in >>>>>>>>>>>>>> general it doesn't make sense to release things that aren't >>>>>>>>>>>>>> functional. >>>>>>>>>>>>>> At >>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all >>>>>>>>>>>>>> of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> components are fully functional yet (for example transaction). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>> Joe >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now >>>>>>>>>>>>>>> out >>>>>>>>>>>>>>> on >>>>>>>>>>>>>>> vacation until monday. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what >>>>>>>>>>>>>>> we >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must >>>>>>>>>>>>>>> haves' >>>>>>>>>>>>>>> are to get the build in the right shape to create the >>>>>>>>>>>>>>> distribution >>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> code deserves at least a README to describe what's possible. >>>>>>>>>>>>>>> Since >>>>>>>>>>>>>>> this is the first release there are likely a few unknowns - >>>>>>>>>>>>>>> w.r.t >>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If >>>>>>>>>>>>>>> there >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be included >>>>>>>>>>>>>>> please >>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> target >>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> new >>>>>>>>>>>>>>> 0.2 version. WDYT? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Jeremy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <[email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jeremy, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the >>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> potential >>>>>>>>>>>>>>>> target dates? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think it would be good if you could summarize your >>>>>>>>>>>>>>>> thoughts >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>> email >>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we >>>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>> progress. >>>>>>>>>>>>>>>> Of particular interest would be the content that we would >>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> the first release (clarifying what we consider "must have" >>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>> "nice >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> have"), the current status of that content, target dates for >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> release, >>>>>>>>>>>>>>>> and the process that we plan to use to generate the release. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jeremy Hughes wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet >>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help. >>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to >>>>>>>>>>>>>>>>>> put >>>>>>>>>>>>>>>>>> those >>>>>>>>>>>>>>>>>> on the wiki. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the >>>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>> changed quite a bit :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes >>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Jeremy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller >>>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all >>>>>>>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>>>>>> at a >>>>>>>>>>>>>>>>>>>> 0.1 >>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning >>>>>>>>>>>>>>>>>>>> scheme, >>>>>>>>>>>>>>>>>>>> IMO. >>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an >>>>>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an >>>>>>>>>>>>>>>>>>>> important >>>>>>>>>>>>>>>>>>>> step >>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this >>>>>>>>>>>>>>>>>>>> happen... >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> --kevan >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>> Open Source SOA >>>>>>>>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Joe >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Joe >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Joe >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Joe >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>> >>> > >
