On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le mer. 5 juin 2019 à 15:59, sebb <seb...@gmail.com> a écrit : > > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > > > Le mer. 5 juin 2019 à 15:18, sebb <seb...@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? > > Maybe, I don't understand the question. > The purpose is to be able to quickly produce several beta releases that > don't have to be compatible with other beta releases but that can coexist > for the purpose of allowing users to compare the impact of the changes.
I don't understand how the user can actually test the release unless they also produce code that is likewise shaded to invoke the appropriate version of the package. Surely it would be easier to test the code if it used the standard package names, i.e. no need to change the user code? i.e. take their app, and run it against the relevant alpha- or beta-release. This is already possible if the user has the ability to compile the component from source. > Gilles > > > > > > Regards, > > > Gilles > > > > > > > > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <boa...@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 <gillese...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
