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

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