Re: [jdf-dev] New versioning and organisation strategy

On Tue, Aug 06, 2013 at 02:03:18PM +0100, Pete Muir wrote: >>> We definitely plan to have archetypes for WF8, just in the sandbox, not in the main repo. >> >> coming back from pto and its great there will be archetypes for WF8 but that doesn't solve the problem of knowing which of now potentially many archetypes for a javaee web app should be used front and center in JBDS Central and we'll need to have maven.enterprise.redhat.com added to users settings.xml for them to work. >> Before we had a default one which could switch between community and product - what do we use in replacement for that 'ease-of-use' feature ? > > Haven't we previously agreed to do this using stacks? Yes, we agreed that would be an option but not made it concrete. Maybe I missed something ? /max >> /max >> >>>> >>>> Now I'm on pto - see you 3 weeks. >>>> >>>> /max (sent from my phone) >>>> >>>> >>>>> On 04/07/2013, at 16.23, Rafael Benevides <benevides(a)redhat.com&gt; wrote: >>>>> >>>>> After considering the feedback and after more brainstorming over the migration plan, we have a now a more detailed and tunned proposal on the new versioning and organization strategy. In the attached PDF you will find this detailed plan with all artifacts changes needed. >>>>> >>>>> It's also a good opportunity to update stacks.yaml format (and client) to 1.1.0 >>>>> >>>>> Please, take a look on the attached plan and let us know what you think about it. The migration work should start by now on developer branches. >>>>> >>>>> Thank you >>>>> >>>>> Em 25/04/13 14:18, Rafael Benevides escreveu: >>>>>> One thing that came in my mind is when to move the versions of Archetypes, Runtimes and BOMs to Stacks.yaml? >>>>>> >>>>>> I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml. >>>>>> >>>>>> In the Case of Archetypes, I'm continuously updating it to the latest version (even being a CR - Candidate Release). >>>>>> >>>>>> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the "Early Access" label. >>>>>> >>>>>> Do we still follow this schema ? >>>>>> >>>>>> BOM: Only -bom-X release ? >>>>>> Archetypes: Every -atype-X release ? >>>>>> Runtime: Every "Early Access" and Product release ? >>>>>> >>>>>> By the way? How will we differ the "Candidate Release" from ".Final" Release ? >>>>>> >>>>>> Em 25/04/13 11:20, Marek Novotny escreveu: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>>>>>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>> Trying to grok consequences. >>>>>>>>> >>>>>>>>> On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. >>>>>>>>> >>>>>>>>> But will the archetypes still support enterprise=true|false flag ? >>>>>>>> No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. >>>>>>>> >>>>>>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? >>>>>>>> No, these are the product BOMs. >>>>>>>> >>>>>>>> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com >>>>>>> that supposes to finish/change the uploading process as >>>>>>> maven.repository.redhat.com's content is currently only extracted >>>>>>> product zips. >>>>>>>>> /max >>>>>>>>> >>>>>>>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >>>>>>>>>> >>>>>>>>>> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >>>>>>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >>>>>>>>>> * quickstarts >>>>>>>>>> - change group id to follow products: >>>>>>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>>>>>> - add a sandbox group id which covers quickstarts not in products >>>>>>>>>> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >>>>>>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>>>>>> * archetypes >>>>>>>>>> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >>>>>>>>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>>>>>>>> * BOMs >>>>>>>>>> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >>>>>>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>>>>>> - projects will be encouraged to create BOMs as well >>>>>>>>>> >>>>>>>>>> Let me know what you think, >>>>>>>>>> >>>>>>>>>> Pete >>>>>>>>>> _______________________________________________ >>>>>>>>>> jdf-dev mailing list >>>>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jdf-dev mailing list >>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>> >>>>>>> - -- Marek Novotny >>>>>>> - -- WFK and Seam Product Lead >>>>>>> >>>>>>> Red Hat Czech s.r.o. >>>>>>> Purkynova 99 >>>>>>> 612 45 Brno >>>>>>> _______________________________________________ >>>>>>> jdf-dev mailing list >>>>>>> jdf-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>> >>>>> <Newversionandorganizationstrategy.pdf> >>>>> _______________________________________________ >>>>> jdf-dev mailing list >>>>> jdf-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>> > > > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev