You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@gmail.com> on 2019/06/04 12:42:17 UTC
[All] Alpha/beta releases
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
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 17:02, James Carman <ja...@carmanconsulting.com> a écrit :
>
> Wouldn’t you have a package collision between two different alpha releases?
Ah, I got it:
In "1.0-alpha1", class "o.a.c.somecomp.alpha1.Foo".
In "1.2-alpha1", class "o.a.c.somecomp.alpha1.Foo".
But those 2 classes can very well be different and incompatible.
However, we can consider that after the release of "1.0", all
"1.0-alphaX" releases are obsolete and serve zero purpose.
The beta releases are "comparable" only within the same base
(unreleased) version.
Gilles
>
> On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Le mer. 5 juin 2019 à 16:47, James Carman <ja...@carmanconsulting.com> a
> > écrit :
> > >
> > > Ok, what about 1.2?
> >
> > How is it different?
> >
> > Gilles
> >
> > >
> > > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > >
> > > > Le mer. 5 juin 2019 à 16:18, James Carman <ja...@carmanconsulting.com>
> > a
> > > > écrit :
> > > > >
> > > > > What happens if/when you want to release a 2.0-alpha1 in the future?
> > > >
> > > > Hmm, what happens?
> > > > [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
> > > >
> > > > Gilles
> > > >
> > > > >
> > > > > On Tue, Jun 4, 2019 at 6:53 AM 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
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
Wouldn’t you have a package collision between two different alpha releases?
On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Le mer. 5 juin 2019 à 16:47, James Carman <ja...@carmanconsulting.com> a
> écrit :
> >
> > Ok, what about 1.2?
>
> How is it different?
>
> Gilles
>
> >
> > On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 16:18, James Carman <ja...@carmanconsulting.com>
> a
> > > écrit :
> > > >
> > > > What happens if/when you want to release a 2.0-alpha1 in the future?
> > >
> > > Hmm, what happens?
> > > [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
> > >
> > > Gilles
> > >
> > > >
> > > > On Tue, Jun 4, 2019 at 6:53 AM 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
>
>
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 16:47, James Carman <ja...@carmanconsulting.com> a écrit :
>
> Ok, what about 1.2?
How is it different?
Gilles
>
> On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Le mer. 5 juin 2019 à 16:18, James Carman <ja...@carmanconsulting.com> a
> > écrit :
> > >
> > > What happens if/when you want to release a 2.0-alpha1 in the future?
> >
> > Hmm, what happens?
> > [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
> >
> > Gilles
> >
> > >
> > > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski <gi...@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
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
Ok, what about 1.2?
On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Le mer. 5 juin 2019 à 16:18, James Carman <ja...@carmanconsulting.com> a
> écrit :
> >
> > What happens if/when you want to release a 2.0-alpha1 in the future?
>
> Hmm, what happens?
> [At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
>
> Gilles
>
> >
> > On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski <gi...@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
>
>
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 16:18, James Carman <ja...@carmanconsulting.com> a écrit :
>
> What happens if/when you want to release a 2.0-alpha1 in the future?
Hmm, what happens?
[At point, we'd have renamed "o.a.c.compid" to ""o.a.c.compid2".]
Gilles
>
> On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski <gi...@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
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
What happens if/when you want to release a 2.0-alpha1 in the future?
On Tue, Jun 4, 2019 at 6:53 AM Gilles Sadowski <gi...@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
>
>
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le dim. 9 juin 2019 à 21:52, Karl Heinz Marbaise <kh...@gmx.de> a écrit :
>
> Hi,
>
> first I don't understand why you really like to 1.0-alpha or somehting
> similar?
>
> Why not following semantical versioning and say if it's not yet 1.0.0
> than just simply release a 0.X.Y version. This makes clear the version
> is not yet 1.0.0 and not finished and can be changed/break things..
Assuming version is "0.1", what is the (top-level) package name?
AFAIK, all Commons libraries use the convention
1.X -> o.a.c.numbers
2.X -> o.a.c.numbers2
> This can be done also for things on going to 2.0.0... this means it's
> major version change which is not compatible with 1.X.X...
What is the package name in "2.0.0"?
> What will tell me a version 2.0.0-alpha/beta? So this will tell people
> there could be bugs in there? But isn't that always the case...
I'm not sure we agree on the premises, so it's hard to answer.
>
> so why not naming the version 2.0.0 and if there is a bug just create a
> 2.0.1, 2.0.2 etc. If you have enhancement in funcionality you produce
> 2.1.0 etc. and so on..if you really are not compatible with 2.X than you
> have to name it 3.0.0...(based on that you can use things like jcmpapi,
> revapi etc. which are made for exactly those purposes).
I'm not discussing tools to check compatibility; that's the point here:
not care about compatibility or stability in "X.Y-betaZ", just that there
won't be JAR hell if several are used together.
>
> So furthermore based on the idea of changing package names? Are you
> really want to do so? That will break each code every time you change
> the version? And what kind of problem are you trying to solve?
That's what we've always done (cf. above), to avoid JAR hell.
> If I'm in the position to check a new version of a library I just simply
> upgrade the version (in my pom file or gradle file) and see if
> everything works (build, tests)..If it's fine I simply continue.. That's
> an easy way of upgrading things (or doing that automatically).
>
> If I need to change my code (based on package name changes) If I want to
> upgrade to a newer version of a library except for cases where major
> version changes this will make the acceptance harder than it needs to be.
Am I correct that, contrary to what we've always done, you
suggest, instead of the above:
1.X -> o.a.c.numbers
2.X -> o.a.c.numbers (same package name)
?
>
> Another thing I see in the discussion about changing groupId/artifactId
> for a change in version? Simply to say that: It is not intended for such
> things. The intended element for this is the version which could be
> expressed by that (see above).
IIUC, that concurs with a "yes" to my previous question.
>
> Suppose you will change the groupId/artifactId. You will get conflicting
> packages/class names. You could have different dependencies in your
> project (groupId/artifactId) are different but contain the same package
> and clashing classnames.
>
> So the consequence would be to change the package names as well?
Of course (cf. above and previous messages in this thread).
>
> The result would be duplicated classes of the same content within
> different packages (or slightly different classes; much worse)?
The price to pay for avoiding JAR hell.
It's up to the user to not depend on different major versions, if
doesn't need to.
> Much
> more complicated and does not really solve the problem cause in the end
> this can not be solved by using things like that (alphas/betas changing
> maven coordinates).
I don't understand.
How would you provide JARs for testing purposes?
> The consumer of a lib has to check it's code if it's working or not via
> Tests and CI system.
With this proposal, the main purpose is *not* to test users' codes,
but to ensure that the library is correctly designed.
If not, with the current convention for Commons release, we'd
ship
1.0 -> o.a.c.numbers
and, when a flaw is discovered, say, the next day, we'd have
to prepare for
2.0 -> o.a.c.numbers2
I prefer the flaw to be discovered in
1.0-beta1 -> o.a.c.numbers.beta1
so that when it's ironed out we can ship
1.0 -> o.a.c.numbers
>
> Finally one more thing about the whole discussion:
>
> The Java Module System.
>
> Changing packages etc. will simply not work cause the module-info file
> contains the packages which are exported or not ...
?
Of course, the module name would change too.
> apart from that using
> maven-shade-plugin will break modules which means that will break
> anything in such cases. So that would a complete blocker for JDK9+
> (Why would you like to use maven-shade-plugin? You have separated
> modules which can be consumed separately ..?)
The plugin was mentioned just as a means to automate the
renaming of the packages.
>
> Furthermore If you are running on module path you have no classpath
> anymore which means you have only a single module name which must be
> unique..(a little bit like groupId/artifactId).
So?
If we change it, it's unique.
>
> Some thought of mine.
I probably did not understand your point(s).
Regards,
Gilles
>
> Kind regards
> Karl Heinz Marbaise
>
> On 04.06.19 14:42, Gilles Sadowski 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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
first I don't understand why you really like to 1.0-alpha or somehting
similar?
Why not following semantical versioning and say if it's not yet 1.0.0
than just simply release a 0.X.Y version. This makes clear the version
is not yet 1.0.0 and not finished and can be changed/break things..
This can be done also for things on going to 2.0.0... this means it's
major version change which is not compatible with 1.X.X...
What will tell me a version 2.0.0-alpha/beta? So this will tell people
there could be bugs in there? But isn't that always the case...
so why not naming the version 2.0.0 and if there is a bug just create a
2.0.1, 2.0.2 etc. If you have enhancement in funcionality you produce
2.1.0 etc. and so on..if you really are not compatible with 2.X than you
have to name it 3.0.0...(based on that you can use things like jcmpapi,
revapi etc. which are made for exactly those purposes).
So furthermore based on the idea of changing package names? Are you
really want to do so? That will break each code every time you change
the version? And what kind of problem are you trying to solve?
If I'm in the position to check a new version of a library I just simply
upgrade the version (in my pom file or gradle file) and see if
everything works (build, tests)..If it's fine I simply continue.. That's
an easy way of upgrading things (or doing that automatically).
If I need to change my code (based on package name changes) If I want to
upgrade to a newer version of a library except for cases where major
version changes this will make the acceptance harder than it needs to be.
Another thing I see in the discussion about changing groupId/artifactId
for a change in version? Simply to say that: It is not intended for such
things. The intended element for this is the version which could be
expressed by that (see above).
Suppose you will change the groupId/artifactId. You will get conflicting
packages/class names. You could have different dependencies in your
project (groupId/artifactId) are different but contain the same package
and clashing classnames.
So the consequence would be to change the package names as well?
The result would be duplicated classes of the same content within
different packages (or slightly different classes; much worse)? Much
more complicated and does not really solve the problem cause in the end
this can not be solved by using things like that (alphas/betas changing
maven coordinates).
The consumer of a lib has to check it's code if it's working or not via
Tests and CI system.
Finally one more thing about the whole discussion:
The Java Module System.
Changing packages etc. will simply not work cause the module-info file
contains the packages which are exported or not ...apart from that using
maven-shade-plugin will break modules which means that will break
anything in such cases. So that would a complete blocker for JDK9+
(Why would you like to use maven-shade-plugin? You have separated
modules which can be consumed separately ..?)
Furthermore If you are running on module path you have no classpath
anymore which means you have only a single module name which must be
unique..(a little bit like groupId/artifactId).
Some thought of mine.
Kind regards
Karl Heinz Marbaise
On 04.06.19 14:42, Gilles Sadowski 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 16:18, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Le mer. 5 juin 2019 à 15:59, sebb <se...@gmail.com> a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com>
> > wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb <se...@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.
> >
>
> This is over the top IMO. That's what JApiCmp is for unless I am missing
> something.
Seems so. Or I am.
I'm talking about producing official releases; no idea how japicmp
is related...
>
> Gayr
>
>
> >
> > Gilles
> >
> > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > >
> > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Le mer. 5 juin 2019 à 15:59, sebb <se...@gmail.com> a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com>
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb <se...@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.
>
This is over the top IMO. That's what JApiCmp is for unless I am missing
something.
Gayr
>
> Gilles
>
> >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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
>
>
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski <gi...@gmail.com> wrote:
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>
Okay, so the main issue is getting releases out into the hands of
folks sooner rather than later. That, I can get behind for sure.
> IIUC, the former is going to release a beta version without modifying
> the top-level package name. This will create the possibility of JAR
> hell (when 1.0 will be out).
>
I think the package rename piece is the part that is throwing me off.
I'd rather release something as "beta" or "alpha" (we've done this
before IIRC) where folks understand that things can change when the
final release comes out. I would leave the package names intact (they
should be whatever they're going to be in the final release, barring
any reorganization or whatever), however.
> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
> * won't be subject to JAR hell and
> * will be easy (i.e. just add the dependency in the POM file) to
> integrate for people kind enough to give it a try.
> [If it's not easy[1], they won't do it.]
>
Unless you also change the maven coordinates, these two flavors of the
same artifact alpha/beta and "real" will not be able to coexist in the
same maven project, so the JAR hell issue isn't possible. You can't
just change the package names and allow them to coexist. That's why
we change both when we do a major release.
In all, I really like the spirit of this, but I think the answer would
be to just release them as alphas/betas while keeping everything else
(artifactId/package name) intact. Release early, release often! :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le dim. 9 juin 2019 à 15:46, sebb <se...@gmail.com> a écrit :
>
> On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Hi.
> >
> > Le dim. 9 juin 2019 à 14:06, James Carman <ja...@carmanconsulting.com> a écrit :
> > >
> > > On Sun, Jun 9, 2019 at 7:36 AM sebb <se...@gmail.com> wrote:
> > >
> > > >
> > > > Huh?
> > > > That can still cause jar issues, *precisely because* only one jar will
> > > > reach the Java classpath.
> > > >
> > > > Suppose there is jar1 with API-V1.
> > > > This is depended on by app1 and app2.
> > > >
> > > > Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
> > > > Update app2 to use jar2.
> > > >
> > > > Assuming jar2 is a later version than jar1, the classpath will no
> > > > longer contain jar1.
> > > > However jar1 contains objects needed by app1.
> > > >
> > >
> > > My "jar hell" I usually think of is when two different jars are on the
> > > classpath at the same time and they expose the same class name.
> > > You're talking about the transitive dependency "jar hell" which
> > > definitely can happen. Sorry for my confusion.
> > >
> > > So, in order to get two different jars on the classpath at the same
> > > time (which I thought was what the original request was about in order
> > > to compare APIs), you'd need to change the maven coordinates to allow
> > > them to co-exist. When you do that, you'll need to change the package
> > > names in order to avoid collisions.
> > >
> > > If folks are publishing jars for others to consume with alpha/beta
> > > dependencies (which may very well change), I'd think that's really not
> > > a good idea and we should document our alpha/beta releases as such
> > > (although that's a pretty standard understanding).
> >
> > Sure, it's not good to depend on "beta"; but it's still better than
> > no code at all. With such releases, developers can start to
> > migrate away from obsolete CM codes, knowing that if all is
> > well, adapting to the final release will only be matter of a trivial
> > update of the "import" statements.
>
> Or just recommend that developers download the current CM branch/tag
> and compile+test against that.
>
> This means no need to change the import statements.
> Which BTW might have to be done multiple times if there are several
> alphas/betas.
>
> And if errors are found in the user code, they may have to update
> multiple versions.
>
> This all seems a lot of work.
>
> I question whether releasing source-incompatible code is likely to
> encourage more alpha/beta testers compared with requiring users to
> compile the code from source.
The scenario which I'm trying to address is:
* a "supervising" org collects dependencies (only it can change the
POM),
* a developer provides a library (that depends on the new features of
the "beta" release) to that org, as part of a larger software,
* the org will only accept an official release (i.e. not a snapshot, not
an ad-hoc JAR compiled by the developer, and not to do additional
work, such as download the source and make an ad-hoc JAR).
So, the aim is two-fold:
1. *not* a lot work of the org (just change the POM in some appropriate
branch),
2. all the adaptation work is for the developer (and anyone who later
decides to use the new features).
> > > The other option
> > > is to just keep with SNAPSHOTs and tell folks to point to our snapshot
> > > repository.
> >
> > This is a step worse than "beta", as the artefacts can change
> > without notice.
>
> That is always the case with SNAPSHOTs.
And the reason why it is a no-no for the above scenario.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by sebb <se...@gmail.com>.
On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hi.
>
> Le dim. 9 juin 2019 à 14:06, James Carman <ja...@carmanconsulting.com> a écrit :
> >
> > On Sun, Jun 9, 2019 at 7:36 AM sebb <se...@gmail.com> wrote:
> >
> > >
> > > Huh?
> > > That can still cause jar issues, *precisely because* only one jar will
> > > reach the Java classpath.
> > >
> > > Suppose there is jar1 with API-V1.
> > > This is depended on by app1 and app2.
> > >
> > > Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
> > > Update app2 to use jar2.
> > >
> > > Assuming jar2 is a later version than jar1, the classpath will no
> > > longer contain jar1.
> > > However jar1 contains objects needed by app1.
> > >
> >
> > My "jar hell" I usually think of is when two different jars are on the
> > classpath at the same time and they expose the same class name.
> > You're talking about the transitive dependency "jar hell" which
> > definitely can happen. Sorry for my confusion.
> >
> > So, in order to get two different jars on the classpath at the same
> > time (which I thought was what the original request was about in order
> > to compare APIs), you'd need to change the maven coordinates to allow
> > them to co-exist. When you do that, you'll need to change the package
> > names in order to avoid collisions.
> >
> > If folks are publishing jars for others to consume with alpha/beta
> > dependencies (which may very well change), I'd think that's really not
> > a good idea and we should document our alpha/beta releases as such
> > (although that's a pretty standard understanding).
>
> Sure, it's not good to depend on "beta"; but it's still better than
> no code at all. With such releases, developers can start to
> migrate away from obsolete CM codes, knowing that if all is
> well, adapting to the final release will only be matter of a trivial
> update of the "import" statements.
Or just recommend that developers download the current CM branch/tag
and compile+test against that.
This means no need to change the import statements.
Which BTW might have to be done multiple times if there are several
alphas/betas.
And if errors are found in the user code, they may have to update
multiple versions.
This all seems a lot of work.
I question whether releasing source-incompatible code is likely to
encourage more alpha/beta testers compared with requiring users to
compile the code from source.
> > The other option
> > is to just keep with SNAPSHOTs and tell folks to point to our snapshot
> > repository.
>
> This is a step worse than "beta", as the artefacts can change
> without notice.
That is always the case with SNAPSHOTs.
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> 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
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le dim. 9 juin 2019 à 14:06, James Carman <ja...@carmanconsulting.com> a écrit :
>
> On Sun, Jun 9, 2019 at 7:36 AM sebb <se...@gmail.com> wrote:
>
> >
> > Huh?
> > That can still cause jar issues, *precisely because* only one jar will
> > reach the Java classpath.
> >
> > Suppose there is jar1 with API-V1.
> > This is depended on by app1 and app2.
> >
> > Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
> > Update app2 to use jar2.
> >
> > Assuming jar2 is a later version than jar1, the classpath will no
> > longer contain jar1.
> > However jar1 contains objects needed by app1.
> >
>
> My "jar hell" I usually think of is when two different jars are on the
> classpath at the same time and they expose the same class name.
> You're talking about the transitive dependency "jar hell" which
> definitely can happen. Sorry for my confusion.
>
> So, in order to get two different jars on the classpath at the same
> time (which I thought was what the original request was about in order
> to compare APIs), you'd need to change the maven coordinates to allow
> them to co-exist. When you do that, you'll need to change the package
> names in order to avoid collisions.
>
> If folks are publishing jars for others to consume with alpha/beta
> dependencies (which may very well change), I'd think that's really not
> a good idea and we should document our alpha/beta releases as such
> (although that's a pretty standard understanding).
Sure, it's not good to depend on "beta"; but it's still better than
no code at all. With such releases, developers can start to
migrate away from obsolete CM codes, knowing that if all is
well, adapting to the final release will only be matter of a trivial
update of the "import" statements.
> The other option
> is to just keep with SNAPSHOTs and tell folks to point to our snapshot
> repository.
This is a step worse than "beta", as the artefacts can change
without notice.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Jun 9, 2019 at 7:36 AM sebb <se...@gmail.com> wrote:
>
> Huh?
> That can still cause jar issues, *precisely because* only one jar will
> reach the Java classpath.
>
> Suppose there is jar1 with API-V1.
> This is depended on by app1 and app2.
>
> Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
> Update app2 to use jar2.
>
> Assuming jar2 is a later version than jar1, the classpath will no
> longer contain jar1.
> However jar1 contains objects needed by app1.
>
My "jar hell" I usually think of is when two different jars are on the
classpath at the same time and they expose the same class name.
You're talking about the transitive dependency "jar hell" which
definitely can happen. Sorry for my confusion.
So, in order to get two different jars on the classpath at the same
time (which I thought was what the original request was about in order
to compare APIs), you'd need to change the maven coordinates to allow
them to co-exist. When you do that, you'll need to change the package
names in order to avoid collisions.
If folks are publishing jars for others to consume with alpha/beta
dependencies (which may very well change), I'd think that's really not
a good idea and we should document our alpha/beta releases as such
(although that's a pretty standard understanding). The other option
is to just keep with SNAPSHOTs and tell folks to point to our snapshot
repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by sebb <se...@gmail.com>.
On Sun, 9 Jun 2019 at 12:01, James Carman <ja...@carmanconsulting.com> wrote:
>
> On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski <gi...@gmail.com> wrote:
>
> >
> > Ultimately the PMC still needs to vote on the release, no?
> > Hence I don't see what advantage there is in allowing different
> > beta policies. [Of course, no component is required to provide
> > a beta release...]
> > What the proposal aims to avoid is JAR hell because of beta
> > releases that did not change the maven coordinates.
> >
>
> JAR hell will not happen (if using maven) when you do not change the
> maven coordinates. Maven will resolve to only one version of the
> given maven coordinates.
Huh?
That can still cause jar issues, *precisely because* only one jar will
reach the Java classpath.
Suppose there is jar1 with API-V1.
This is depended on by app1 and app2.
Then jar2 is produced with API-V2 (not BC-compatible with API-V1)
Update app2 to use jar2.
Assuming jar2 is a later version than jar1, the classpath will no
longer contain jar1.
However jar1 contains objects needed by app1.
> ---------------------------------------------------------------------
> 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
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski <gi...@gmail.com> wrote:
>
> Ultimately the PMC still needs to vote on the release, no?
> Hence I don't see what advantage there is in allowing different
> beta policies. [Of course, no component is required to provide
> a beta release...]
> What the proposal aims to avoid is JAR hell because of beta
> releases that did not change the maven coordinates.
>
JAR hell will not happen (if using maven) when you do not change the
maven coordinates. Maven will resolve to only one version of the
given maven coordinates.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le jeu. 6 juin 2019 à 15:18, sebb <se...@gmail.com> a écrit :
>
> On Wed, 5 Jun 2019 at 23:40, Gary Gregory <ga...@gmail.com> wrote:
> >
> > Hi All:
> >
> > I see two lines of usage IRL from people:
> >
> > - I use whatever is "released" on Maven Central. I quote the word released
> > since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and
> > -betas.
>
> N.B. This by definition excludes SNAPSHOTs
>
> > - I am not allowed to use alpha, beta, or SNAPSHOT versions.
> >
> > The reality ends up being that you see some stacks that have a mix of both
> > of the above.
> >
> > We all know that Jar hell is created when breaking BC within the same
> > package name (and Maven coordinates.)
>
> Or changing Maven coordinates but not changing the package name.
>
> > We have clear rules of engagement of major, minor and maintenance releases.
> >
> > The question for me is how should we treat other kinds of releases: alphas
> > and betas. This is assuming that we want to keep on releasing alphas and
> > betas.
> >
> > Jar hell is, well, hellish. I like to avoid it.
>
> +1
>
> > Since the very nature of alphas and betas is that changing APIs should be
> > allowed, even encouraged in order to get the API in the right shape before
> > a x.y.z release, I am warming to using alpha and beta in package names...
>
> I thought API changes were restricted to alpha releases and beta for
> behaviour changes?
> But this is a minor detail.
>
> > If you are to be so bold as to use such a thing, then reflecting that in
> > the import states what you are doing clearly, and avoid any jar hell.
>
> Agreed, it's clearly the user choice here since they have to change
> their code (and POM) to use the new package.
>
> Note: this would also require use of new Maven coordinates.
>
> > That said, it should be left to each component to decide whether or not to
> > opt in such naming.
>
> +1
Ultimately the PMC still needs to vote on the release, no?
Hence I don't see what advantage there is in allowing different
beta policies. [Of course, no component is required to provide
a beta release...]
What the proposal aims to avoid is JAR hell because of beta
releases that did not change the maven coordinates.
>
> I think it would be worth documenting step by step how the proposal
> works overall, to make sure that nothing has been overlooked.
> One can then look at whether any additional tooling is needed, or if
> it already exists.
If assuming the release process described for [RNG]:
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=doc/release/release.howto.txt
there would be additional steps before step (1):
* create a branch (say "1.0-beta1") and switch to it
* change the version (to "1.0-beta1") in all the POM files
* change the top-level package names in the POM files
* modify/move the source files accordingly
Ideally, all this would happen automagically by adding
-Dcommons.release.pre=beta1
to the command referred to in step (1) in the release howto.
[The setting would be picked-up by the release profile or
build plugin, I guess.]
The rest of the process is unchanged.
Please note that the initial idea was whether we could do
away with part of the regular review of the release (no
compatibility requirement, no web site, no archiving, ...), on
the basis that such alpha/beta releases would not benefit
from any of the usual support, except for beta-testing. [It
was the purpose of asking whether this could be handled by
just "shading" the whole library and create the executable
maven artefacts.]
If this is too brittle to get accepted because there is no
Apache policy for this, then we'd use the usual process
(explicitly create the modified sources and keep all the
beta branches indefinitely...), hopefully automated by the
build-plugin as per the above suggestion.
Regards,
Gilles
> > Gary
> >
> >
> > On Wed, Jun 5, 2019 at 6:25 PM Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > > Le mer. 5 juin 2019 à 23:14, sebb <se...@gmail.com> a écrit :
> > > >
> > > > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > > > >
> > > > > Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com>
> > > a écrit :
> > > > > >
> > > > > > I’m having a hard time understanding the comparing APIs use case.
> > > If I
> > > > > > were to want to try that, I’d create a branch and import the new
> > > dependency
> > > > > > version and see what breaks. The performance part I wouldn’t think
> > > I’d use
> > > > > > one code base either. I’m not suggesting my way is the only or best
> > > way,
> > > > > > just explaining why I’m having a hard time understanding what you’re
> > > > > > doing. Maybe this will be a learning opportunity for me! :)
> > > > >
> > > > > Case mainly in point is getting to the first release of new components.
> > > > > This is happening now for [Imaging], and will be soon (hopefully) for
> > > > > [Numbers], [Statistics] and [Geometry].
> > > > >
> > > > > IIUC, the former is going to release a beta version without modifying
> > > > > the top-level package name. This will create the possibility of JAR
> > > > > hell (when 1.0 will be out).
> > > > >
> > > > > Since we don't have that much review/feedback on these new and/or
> > > > > refactored codes, I thought we could be on a safer ground if we first
> > > > > release beta version(s) that
> > > > > * won't be subject to JAR hell and
> > > > > * will be easy (i.e. just add the dependency in the POM file) to
> > > > > integrate for people kind enough to give it a try.
> > > > > [If it's not easy[1], they won't do it.]
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > > [1] Like: You "just" have to install "git", check out the source,
> > > install
> > > > > "maven", run the "package" goal, then move the "target/whatever.jar"
> > > > > file to where your code will look for it.
> > > >
> > > > No need to install Git; can just download the source archive and unpack
> > > it.
> > > > I think we can assume they already have Maven, otherwise why are we
> > > > worried about releasing to Maven?
> > > >
> > > > Note that the suggestion of using different package names will force
> > > > users to edit their code.
> > >
> > > So what; this is the purpose of beta-testing features that don't
> > > exist in previous releases or in the previous beta version.
> > >
> > > > They will then have to compile their source, probably using Maven.
> > > >
> > > > Seems to me the suggestion creates more work for end users.
> > >
> > > People will have to do something.
> > > When they raise an issue, it is easier for me and for them to point
> > > to one-line change in their dependencies (and the corresponding
> > > change in their code), then to start explaining that they should
> > > build from source.
> > >
> > > From the discussion, I'm still missing the opinion stating explicitly
> > > that "we don't care about JAR hell produced by a beta release".
> > > My suggestion is only to avoid that. Is the PMC fine releasing
> > > *incompatible* beta releases (and of course incompatible with the
> > > "stable" release that will follow) with the same package name?
> > >
> > > Gilles
> > >
> > > > > >
> > > > > > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <
> > > gilleseran@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Le mer. 5 juin 2019 à 17:04, James Carman <
> > > james@carmanconsulting.com> a
> > > > > > > écrit :
> > > > > > > >
> > > > > > > > What sort of comparison are you looking to do within the same
> > > code?
> > > > > > > > Performance?
> > > > > > >
> > > > > > > Yes, that's one possibility; another is comparing different APIs.
> > > > > > >
> > > > > > > Gilles
> > > > > > >
> > > > > > > >>>> [...]
> > > > > > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by sebb <se...@gmail.com>.
On Wed, 5 Jun 2019 at 23:40, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All:
>
> I see two lines of usage IRL from people:
>
> - I use whatever is "released" on Maven Central. I quote the word released
> since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and
> -betas.
N.B. This by definition excludes SNAPSHOTs
> - I am not allowed to use alpha, beta, or SNAPSHOT versions.
>
> The reality ends up being that you see some stacks that have a mix of both
> of the above.
>
> We all know that Jar hell is created when breaking BC within the same
> package name (and Maven coordinates.)
Or changing Maven coordinates but not changing the package name.
> We have clear rules of engagement of major, minor and maintenance releases.
>
> The question for me is how should we treat other kinds of releases: alphas
> and betas. This is assuming that we want to keep on releasing alphas and
> betas.
>
> Jar hell is, well, hellish. I like to avoid it.
+1
> Since the very nature of alphas and betas is that changing APIs should be
> allowed, even encouraged in order to get the API in the right shape before
> a x.y.z release, I am warming to using alpha and beta in package names...
I thought API changes were restricted to alpha releases and beta for
behaviour changes?
But this is a minor detail.
> If you are to be so bold as to use such a thing, then reflecting that in
> the import states what you are doing clearly, and avoid any jar hell.
Agreed, it's clearly the user choice here since they have to change
their code (and POM) to use the new package.
Note: this would also require use of new Maven coordinates.
> That said, it should be left to each component to decide whether or not to
> opt in such naming.
+1
I think it would be worth documenting step by step how the proposal
works overall, to make sure that nothing has been overlooked.
One can then look at whether any additional tooling is needed, or if
it already exists.
> Gary
>
>
> On Wed, Jun 5, 2019 at 6:25 PM Gilles Sadowski <gi...@gmail.com> wrote:
>
> > Le mer. 5 juin 2019 à 23:14, sebb <se...@gmail.com> a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski <gi...@gmail.com>
> > wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com>
> > a écrit :
> > > > >
> > > > > I’m having a hard time understanding the comparing APIs use case.
> > If I
> > > > > were to want to try that, I’d create a branch and import the new
> > dependency
> > > > > version and see what breaks. The performance part I wouldn’t think
> > I’d use
> > > > > one code base either. I’m not suggesting my way is the only or best
> > way,
> > > > > just explaining why I’m having a hard time understanding what you’re
> > > > > doing. Maybe this will be a learning opportunity for me! :)
> > > >
> > > > Case mainly in point is getting to the first release of new components.
> > > > This is happening now for [Imaging], and will be soon (hopefully) for
> > > > [Numbers], [Statistics] and [Geometry].
> > > >
> > > > IIUC, the former is going to release a beta version without modifying
> > > > the top-level package name. This will create the possibility of JAR
> > > > hell (when 1.0 will be out).
> > > >
> > > > Since we don't have that much review/feedback on these new and/or
> > > > refactored codes, I thought we could be on a safer ground if we first
> > > > release beta version(s) that
> > > > * won't be subject to JAR hell and
> > > > * will be easy (i.e. just add the dependency in the POM file) to
> > > > integrate for people kind enough to give it a try.
> > > > [If it's not easy[1], they won't do it.]
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > [1] Like: You "just" have to install "git", check out the source,
> > install
> > > > "maven", run the "package" goal, then move the "target/whatever.jar"
> > > > file to where your code will look for it.
> > >
> > > No need to install Git; can just download the source archive and unpack
> > it.
> > > I think we can assume they already have Maven, otherwise why are we
> > > worried about releasing to Maven?
> > >
> > > Note that the suggestion of using different package names will force
> > > users to edit their code.
> >
> > So what; this is the purpose of beta-testing features that don't
> > exist in previous releases or in the previous beta version.
> >
> > > They will then have to compile their source, probably using Maven.
> > >
> > > Seems to me the suggestion creates more work for end users.
> >
> > People will have to do something.
> > When they raise an issue, it is easier for me and for them to point
> > to one-line change in their dependencies (and the corresponding
> > change in their code), then to start explaining that they should
> > build from source.
> >
> > From the discussion, I'm still missing the opinion stating explicitly
> > that "we don't care about JAR hell produced by a beta release".
> > My suggestion is only to avoid that. Is the PMC fine releasing
> > *incompatible* beta releases (and of course incompatible with the
> > "stable" release that will follow) with the same package name?
> >
> > Gilles
> >
> > > > >
> > > > > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <
> > gilleseran@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le mer. 5 juin 2019 à 17:04, James Carman <
> > james@carmanconsulting.com> a
> > > > > > écrit :
> > > > > > >
> > > > > > > What sort of comparison are you looking to do within the same
> > code?
> > > > > > > Performance?
> > > > > >
> > > > > > Yes, that's one possibility; another is comparing different APIs.
> > > > > >
> > > > > > Gilles
> > > > > >
> > > > > > >>>> [...]
> > > > > >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [All] Alpha/beta releases
Posted by Gary Gregory <ga...@gmail.com>.
Hi All:
I see two lines of usage IRL from people:
- I use whatever is "released" on Maven Central. I quote the word released
since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and
-betas.
- I am not allowed to use alpha, beta, or SNAPSHOT versions.
The reality ends up being that you see some stacks that have a mix of both
of the above.
We all know that Jar hell is created when breaking BC within the same
package name (and Maven coordinates.)
We have clear rules of engagement of major, minor and maintenance releases.
The question for me is how should we treat other kinds of releases: alphas
and betas. This is assuming that we want to keep on releasing alphas and
betas.
Jar hell is, well, hellish. I like to avoid it.
Since the very nature of alphas and betas is that changing APIs should be
allowed, even encouraged in order to get the API in the right shape before
a x.y.z release, I am warming to using alpha and beta in package names...
If you are to be so bold as to use such a thing, then reflecting that in
the import states what you are doing clearly, and avoid any jar hell.
That said, it should be left to each component to decide whether or not to
opt in such naming.
Gary
On Wed, Jun 5, 2019 at 6:25 PM Gilles Sadowski <gi...@gmail.com> wrote:
> Le mer. 5 juin 2019 à 23:14, sebb <se...@gmail.com> a écrit :
> >
> > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski <gi...@gmail.com>
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com>
> a écrit :
> > > >
> > > > I’m having a hard time understanding the comparing APIs use case.
> If I
> > > > were to want to try that, I’d create a branch and import the new
> dependency
> > > > version and see what breaks. The performance part I wouldn’t think
> I’d use
> > > > one code base either. I’m not suggesting my way is the only or best
> way,
> > > > just explaining why I’m having a hard time understanding what you’re
> > > > doing. Maybe this will be a learning opportunity for me! :)
> > >
> > > Case mainly in point is getting to the first release of new components.
> > > This is happening now for [Imaging], and will be soon (hopefully) for
> > > [Numbers], [Statistics] and [Geometry].
> > >
> > > IIUC, the former is going to release a beta version without modifying
> > > the top-level package name. This will create the possibility of JAR
> > > hell (when 1.0 will be out).
> > >
> > > Since we don't have that much review/feedback on these new and/or
> > > refactored codes, I thought we could be on a safer ground if we first
> > > release beta version(s) that
> > > * won't be subject to JAR hell and
> > > * will be easy (i.e. just add the dependency in the POM file) to
> > > integrate for people kind enough to give it a try.
> > > [If it's not easy[1], they won't do it.]
> > >
> > > Regards,
> > > Gilles
> > >
> > > [1] Like: You "just" have to install "git", check out the source,
> install
> > > "maven", run the "package" goal, then move the "target/whatever.jar"
> > > file to where your code will look for it.
> >
> > No need to install Git; can just download the source archive and unpack
> it.
> > I think we can assume they already have Maven, otherwise why are we
> > worried about releasing to Maven?
> >
> > Note that the suggestion of using different package names will force
> > users to edit their code.
>
> So what; this is the purpose of beta-testing features that don't
> exist in previous releases or in the previous beta version.
>
> > They will then have to compile their source, probably using Maven.
> >
> > Seems to me the suggestion creates more work for end users.
>
> People will have to do something.
> When they raise an issue, it is easier for me and for them to point
> to one-line change in their dependencies (and the corresponding
> change in their code), then to start explaining that they should
> build from source.
>
> From the discussion, I'm still missing the opinion stating explicitly
> that "we don't care about JAR hell produced by a beta release".
> My suggestion is only to avoid that. Is the PMC fine releasing
> *incompatible* beta releases (and of course incompatible with the
> "stable" release that will follow) with the same package name?
>
> Gilles
>
> > > >
> > > > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <
> gilleseran@gmail.com>
> > > > wrote:
> > > >
> > > > > Le mer. 5 juin 2019 à 17:04, James Carman <
> james@carmanconsulting.com> a
> > > > > écrit :
> > > > > >
> > > > > > What sort of comparison are you looking to do within the same
> code?
> > > > > > Performance?
> > > > >
> > > > > Yes, that's one possibility; another is comparing different APIs.
> > > > >
> > > > > Gilles
> > > > >
> > > > > >>>> [...]
> > > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 23:14, sebb <se...@gmail.com> a écrit :
>
> On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com> a écrit :
> > >
> > > I’m having a hard time understanding the comparing APIs use case. If I
> > > were to want to try that, I’d create a branch and import the new dependency
> > > version and see what breaks. The performance part I wouldn’t think I’d use
> > > one code base either. I’m not suggesting my way is the only or best way,
> > > just explaining why I’m having a hard time understanding what you’re
> > > doing. Maybe this will be a learning opportunity for me! :)
> >
> > Case mainly in point is getting to the first release of new components.
> > This is happening now for [Imaging], and will be soon (hopefully) for
> > [Numbers], [Statistics] and [Geometry].
> >
> > IIUC, the former is going to release a beta version without modifying
> > the top-level package name. This will create the possibility of JAR
> > hell (when 1.0 will be out).
> >
> > Since we don't have that much review/feedback on these new and/or
> > refactored codes, I thought we could be on a safer ground if we first
> > release beta version(s) that
> > * won't be subject to JAR hell and
> > * will be easy (i.e. just add the dependency in the POM file) to
> > integrate for people kind enough to give it a try.
> > [If it's not easy[1], they won't do it.]
> >
> > Regards,
> > Gilles
> >
> > [1] Like: You "just" have to install "git", check out the source, install
> > "maven", run the "package" goal, then move the "target/whatever.jar"
> > file to where your code will look for it.
>
> No need to install Git; can just download the source archive and unpack it.
> I think we can assume they already have Maven, otherwise why are we
> worried about releasing to Maven?
>
> Note that the suggestion of using different package names will force
> users to edit their code.
So what; this is the purpose of beta-testing features that don't
exist in previous releases or in the previous beta version.
> They will then have to compile their source, probably using Maven.
>
> Seems to me the suggestion creates more work for end users.
People will have to do something.
When they raise an issue, it is easier for me and for them to point
to one-line change in their dependencies (and the corresponding
change in their code), then to start explaining that they should
build from source.
From the discussion, I'm still missing the opinion stating explicitly
that "we don't care about JAR hell produced by a beta release".
My suggestion is only to avoid that. Is the PMC fine releasing
*incompatible* beta releases (and of course incompatible with the
"stable" release that will follow) with the same package name?
Gilles
> > >
> > > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > >
> > > > Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a
> > > > écrit :
> > > > >
> > > > > What sort of comparison are you looking to do within the same code?
> > > > > Performance?
> > > >
> > > > Yes, that's one possibility; another is comparing different APIs.
> > > >
> > > > Gilles
> > > >
> > > > >>>> [...]
> > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by sebb <se...@gmail.com>.
On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com> a écrit :
> >
> > I’m having a hard time understanding the comparing APIs use case. If I
> > were to want to try that, I’d create a branch and import the new dependency
> > version and see what breaks. The performance part I wouldn’t think I’d use
> > one code base either. I’m not suggesting my way is the only or best way,
> > just explaining why I’m having a hard time understanding what you’re
> > doing. Maybe this will be a learning opportunity for me! :)
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>
> IIUC, the former is going to release a beta version without modifying
> the top-level package name. This will create the possibility of JAR
> hell (when 1.0 will be out).
>
> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
> * won't be subject to JAR hell and
> * will be easy (i.e. just add the dependency in the POM file) to
> integrate for people kind enough to give it a try.
> [If it's not easy[1], they won't do it.]
>
> Regards,
> Gilles
>
> [1] Like: You "just" have to install "git", check out the source, install
> "maven", run the "package" goal, then move the "target/whatever.jar"
> file to where your code will look for it.
No need to install Git; can just download the source archive and unpack it.
I think we can assume they already have Maven, otherwise why are we
worried about releasing to Maven?
Note that the suggestion of using different package names will force
users to edit their code.
They will then have to compile their source, probably using Maven.
Seems to me the suggestion creates more work for end users.
> >
> > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a
> > > écrit :
> > > >
> > > > What sort of comparison are you looking to do within the same code?
> > > > Performance?
> > >
> > > Yes, that's one possibility; another is comparing different APIs.
> > >
> > > Gilles
> > >
> > > >>>> [...]
> > >
> > > ---------------------------------------------------------------------
> > > 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
Re: [All] Alpha/beta releases
Posted by Otto Fowler <ot...@gmail.com>.
On June 5, 2019 at 12:16:33, Gilles Sadowski (gilleseran@gmail.com) wrote:
Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com> a
écrit :
>
> I’m having a hard time understanding the comparing APIs use case. If I
> were to want to try that, I’d create a branch and import the new
dependency
> version and see what breaks. The performance part I wouldn’t think I’d use
> one code base either. I’m not suggesting my way is the only or best way,
> just explaining why I’m having a hard time understanding what you’re
> doing. Maybe this will be a learning opportunity for me! :)
Case mainly in point is getting to the first release of new components.
This is happening now for [Imaging], and will be soon (hopefully) for
[Numbers], [Statistics] and [Geometry].
IIUC, the former is going to release a beta version without modifying
the top-level package name. This will create the possibility of JAR
hell (when 1.0 will be out).
Sounds like the issue is doing ‘alpha’ and ‘beta’ releases instead of just
using versioning.
Since we don't have that much review/feedback on these new and/or
refactored codes, I thought we could be on a safer ground if we first
release beta version(s) that
* won't be subject to JAR hell and
* will be easy (i.e. just add the dependency in the POM file) to
integrate for people kind enough to give it a try.
[If it's not easy[1], they won't do it.]
Regards,
Gilles
[1] Like: You "just" have to install "git", check out the source, install
"maven", run the "package" goal, then move the "target/whatever.jar"
file to where your code will look for it.
>
> On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a
> > écrit :
> > >
> > > What sort of comparison are you looking to do within the same code?
> > > Performance?
> >
> > Yes, that's one possibility; another is comparing different APIs.
> >
> > Gilles
> >
> > >>>> [...]
> >
> > ---------------------------------------------------------------------
> > 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
Re: [All] Alpha/beta releases
Posted by Gary Gregory <ga...@gmail.com>.
In the past we have only guarded against jar-hell with major component
releases matching a package name changes and Maven coordinate name change.
It seems some want to apply the same principles to other kinds of versions,
not just major version. Like a 0.9.alpha1 or even a 2.0.beta-1. I suppose
there is nothing stopping us from that...
Gary
On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski <gi...@gmail.com>
wrote:
> Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com> a
> écrit :
> >
> > I’m having a hard time understanding the comparing APIs use case. If I
> > were to want to try that, I’d create a branch and import the new
> dependency
> > version and see what breaks. The performance part I wouldn’t think I’d
> use
> > one code base either. I’m not suggesting my way is the only or best way,
> > just explaining why I’m having a hard time understanding what you’re
> > doing. Maybe this will be a learning opportunity for me! :)
>
> Case mainly in point is getting to the first release of new components.
> This is happening now for [Imaging], and will be soon (hopefully) for
> [Numbers], [Statistics] and [Geometry].
>
> IIUC, the former is going to release a beta version without modifying
> the top-level package name. This will create the possibility of JAR
> hell (when 1.0 will be out).
>
> Since we don't have that much review/feedback on these new and/or
> refactored codes, I thought we could be on a safer ground if we first
> release beta version(s) that
> * won't be subject to JAR hell and
> * will be easy (i.e. just add the dependency in the POM file) to
> integrate for people kind enough to give it a try.
> [If it's not easy[1], they won't do it.]
>
> Regards,
> Gilles
>
> [1] Like: You "just" have to install "git", check out the source, install
> "maven", run the "package" goal, then move the "target/whatever.jar"
> file to where your code will look for it.
>
> >
> > On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> > > Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com>
> a
> > > écrit :
> > > >
> > > > What sort of comparison are you looking to do within the same code?
> > > > Performance?
> > >
> > > Yes, that's one possibility; another is comparing different APIs.
> > >
> > > Gilles
> > >
> > > >>>> [...]
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 17:57, James Carman <ja...@carmanconsulting.com> a écrit :
>
> I’m having a hard time understanding the comparing APIs use case. If I
> were to want to try that, I’d create a branch and import the new dependency
> version and see what breaks. The performance part I wouldn’t think I’d use
> one code base either. I’m not suggesting my way is the only or best way,
> just explaining why I’m having a hard time understanding what you’re
> doing. Maybe this will be a learning opportunity for me! :)
Case mainly in point is getting to the first release of new components.
This is happening now for [Imaging], and will be soon (hopefully) for
[Numbers], [Statistics] and [Geometry].
IIUC, the former is going to release a beta version without modifying
the top-level package name. This will create the possibility of JAR
hell (when 1.0 will be out).
Since we don't have that much review/feedback on these new and/or
refactored codes, I thought we could be on a safer ground if we first
release beta version(s) that
* won't be subject to JAR hell and
* will be easy (i.e. just add the dependency in the POM file) to
integrate for people kind enough to give it a try.
[If it's not easy[1], they won't do it.]
Regards,
Gilles
[1] Like: You "just" have to install "git", check out the source, install
"maven", run the "package" goal, then move the "target/whatever.jar"
file to where your code will look for it.
>
> On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a
> > écrit :
> > >
> > > What sort of comparison are you looking to do within the same code?
> > > Performance?
> >
> > Yes, that's one possibility; another is comparing different APIs.
> >
> > Gilles
> >
> > >>>> [...]
> >
> > ---------------------------------------------------------------------
> > 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
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
I’m having a hard time understanding the comparing APIs use case. If I
were to want to try that, I’d create a branch and import the new dependency
version and see what breaks. The performance part I wouldn’t think I’d use
one code base either. I’m not suggesting my way is the only or best way,
just explaining why I’m having a hard time understanding what you’re
doing. Maybe this will be a learning opportunity for me! :)
On Wed, Jun 5, 2019 at 11:33 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a
> écrit :
> >
> > What sort of comparison are you looking to do within the same code?
> > Performance?
>
> Yes, that's one possibility; another is comparing different APIs.
>
> Gilles
>
> >>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [All] Alpha/beta releases
Posted by Matt Sicker <bo...@gmail.com>.
Maybe we should have a separate maven repo for alpha and beta releases.
That could make them less likely to cause jar hell conflicts. It could even
be similar to snapshots if they’re not voted on.
On Wed, Jun 5, 2019 at 10:33, Gilles Sadowski <gi...@gmail.com> wrote:
> Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a
> écrit :
> >
> > What sort of comparison are you looking to do within the same code?
> > Performance?
>
> Yes, that's one possibility; another is comparing different APIs.
>
> Gilles
>
> >>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 17:04, James Carman <ja...@carmanconsulting.com> a écrit :
>
> What sort of comparison are you looking to do within the same code?
> Performance?
Yes, that's one possibility; another is comparing different APIs.
Gilles
>>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by James Carman <ja...@carmanconsulting.com>.
What sort of comparison are you looking to do within the same code?
Performance?
On Wed, Jun 5, 2019 at 10:54 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Le mer. 5 juin 2019 à 16:22, sebb <se...@gmail.com> a écrit :
> >
> > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <gi...@gmail.com>
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:59, sebb <se...@gmail.com> a écrit :
> > > >
> > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com>
> wrote:
> > > > >
> > > > > Le mer. 5 juin 2019 à 15:18, sebb <se...@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.
>
> Of course, if they want to test "alpha1", they need to depend on it,
> and modify their code accordingly.
>
> > 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?
>
> Yes, but that means that we cannot compare "alpha1" and "alpha2" in
> the same code.
>
> > i.e. take their app, and run it against the relevant alpha- or
> beta-release.
>
> Then the main concern is the possibility of JAR hell (e.g. when several
> "alpha" are in the classpath).
>
> > This is already possible if the user has the ability to compile the
> > component from source.
>
> I think that If we hope to get help from users, we should provide a JAR.
>
> Regards,
> Gilles
>
> >
> > > Gilles
> > >
> > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > > >
> > > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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
>
>
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 16:22, sebb <se...@gmail.com> a écrit :
>
> On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mer. 5 juin 2019 à 15:59, sebb <se...@gmail.com> a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com> wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb <se...@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.
Of course, if they want to test "alpha1", they need to depend on it,
and modify their code accordingly.
> 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?
Yes, but that means that we cannot compare "alpha1" and "alpha2" in
the same code.
> i.e. take their app, and run it against the relevant alpha- or beta-release.
Then the main concern is the possibility of JAR hell (e.g. when several
"alpha" are in the classpath).
> This is already possible if the user has the ability to compile the
> component from source.
I think that If we hope to get help from users, we should provide a JAR.
Regards,
Gilles
>
> > Gilles
> >
> > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > >
> > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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
Re: [All] Alpha/beta releases
Posted by sebb <se...@gmail.com>.
On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mer. 5 juin 2019 à 15:59, sebb <se...@gmail.com> a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb <se...@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 <bo...@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 <gi...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 15:59, sebb <se...@gmail.com> a écrit :
>
> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb <se...@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.
Gilles
>
> > Regards,
> > Gilles
> >
> > >
> > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 16:04, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Wed, Jun 5, 2019 at 9:59 AM sebb <se...@gmail.com> wrote:
>
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb <se...@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.
The script/profile/whatever could be:
1. create a "beta-release-2.3-alpha1" branch
2. perform the top-level package name change
3. commit
4. proceed as usual
Gilles
> Gary
>
>
> >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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
Re: [All] Alpha/beta releases
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jun 5, 2019 at 9:59 AM sebb <se...@gmail.com> wrote:
> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb <se...@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 <bo...@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 <gi...@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 <bo...@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
>
>
Re: [All] Alpha/beta releases
Posted by sebb <se...@gmail.com>.
On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mer. 5 juin 2019 à 15:18, sebb <se...@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?
> Regards,
> Gilles
>
> >
> > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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 <bo...@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
Re: [All] Alpha/beta releases
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 5 juin 2019 à 15:18, sebb <se...@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
Regards,
Gilles
>
> On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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 <bo...@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
Re: [All] Alpha/beta releases
Posted by sebb <se...@gmail.com>.
I'm not sure what problem this is trying to solve.
How is it intended to use the facility?
On Tue, 4 Jun 2019 at 17:35, Matt Sicker <bo...@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 <gi...@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 <bo...@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
Re: [All] Alpha/beta releases
Posted by Matt Sicker <bo...@gmail.com>.
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 <gi...@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 <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org