Hi.
Le jeu. 6 juin 2019 à 15:18, sebb <seb...@gmail.com> a écrit :
>
> On Wed, 5 Jun 2019 at 23:40, Gary Gregory <garydgreg...@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 <gillese...@gmail.com> wrote:
> >
> > > Le mer. 5 juin 2019 à 23:14, sebb <seb...@gmail.com> a écrit :
> > > >
> > > > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski <gillese...@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 <
> > > gillese...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
