commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [All] Alpha/beta releases
Date Wed, 05 Jun 2019 14:03:42 GMT
On Wed, Jun 5, 2019 at 9:59 AM sebb <sebbaz@gmail.com> wrote:

> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gilleseran@gmail.com> wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb <sebbaz@gmail.com> a écrit :
> > >
> > > I'm not sure what problem this is trying to solve.
> > >
> > > How is it intended to use the facility?
> >
> > Ideally:
> >     $ mvn -Pbetarelease [... other settings ...] -Dbetasubversion=alpha1
> > where the latter profile would take care of changing the
> > toplevel package name
> >     o.a.c.somecomp
> > to
> >     o.a.c.somecomp.alpha1
> >
> > And, if the upcoming version is, say, "2.3", the generated
> > artefact(s) would be:
> >   commons-somecomp-2.3-alpha1
>
> That's not what I intended to ask.
>
> What problem does the ability to readily change the package name actually
> solve?
> And how are the amended packages going to be used?
>

Also, the renamed sources would need to be in git as well.

Gary


>
> > Regards,
> > Gilles
> >
> > >
> > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <boards@gmail.com> wrote:
> > > >
> > > > This sounds like a shade feature, yes. However, in order to
> > > > automatically extract the version extra data and detect a version
> > > > keyword like "alpha" may require some additional code, though maybe
> > > > the shade plugin already supports that.
> > > >
> > > > Alternatively, JUnit 5.x uses a tool called API Guardian for marking
> > > > which APIs are stable or not:
> > > > https://github.com/apiguardian-team/apiguardian
> > > >
> > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski <gilleseran@gmail.com>
> wrote:
> > > > >
> > > > > Hello.
> > > > >
> > > > > Does someone see a practical way to automate package names
> > > > > and source files conversions so that each all alpha/beta releases
> > > > > can be used together (e.g. to compare their behaviours).
> > > > >
> > > > > I mean, for release version "1.0-alpha1", the top-level package
> > > > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1".
> > > > >
> > > > > This would also solve issues with compatibility checkers (with the
> > > > > added bonus that JAR hell could never happen).
> > > > >
> > > > > Couldn't the "shade" plugin be put to use (so that all artefacts
> have
> > > > > their top-level package transparently set to "o.a.c.compid.alpha1"
> > > > > and all the tools operate on that)?
> > > > >
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <boards@gmail.com>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message