[jdf-dev] New versioning and organisation strategy

[Jason Porter]

Will this incorporate the versioning changes we discussed at JUDCon:Brazil?

----- Original Message -----
> From: "Rafael Benevides" <benevides at redhat.com>
> To: jdf-dev at lists.jboss.org, "Peter Muir" <pmuir at redhat.com>
> Sent: Thursday, July 4, 2013 8:22:29 AM
> Subject: Re: [jdf-dev] New versioning and organisation strategy
> 
> 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 at redhat.com>
> >>> 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 at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev
> >>>
> >>> _______________________________________________
> >>> jdf-dev mailing list
> >>> jdf-dev at 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
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.12 (GNU/Linux)
> >> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> >>
> >> iEYEARECAAYFAlF5O8sACgkQU4HO8G8hNxXwkACdHa/hQ2cX1lF7FfjB7KblcaWF
> >> HZIAoLpXaKeyW4aEu9eWk/m+Pu75PvcY
> >> =68YA
> >> -----END PGP SIGNATURE-----
> >> _______________________________________________
> >> jdf-dev mailing list
> >> jdf-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jdf-dev
> >
> 
> 
> _______________________________________________
> jdf-dev mailing list
> jdf-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jdf-dev