Le dim. 9 juin 2019 à 21:52, Karl Heinz Marbaise 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 versio
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..
Th
Le dim. 9 juin 2019 à 15:46, sebb a écrit :
>
> On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski wrote:
> >
> > Hi.
> >
> > Le dim. 9 juin 2019 à 14:06, James Carman a
> > écrit :
> > >
> > > On Sun, Jun 9, 2019 at 7:36 AM sebb wrote:
> > >
> > > >
> > > > Huh?
> > > > That can still cause jar iss
On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski wrote:
>
> Hi.
>
> Le dim. 9 juin 2019 à 14:06, James Carman a
> écrit :
> >
> > On Sun, Jun 9, 2019 at 7:36 AM sebb wrote:
> >
> > >
> > > Huh?
> > > That can still cause jar issues, *precisely because* only one jar will
> > > reach the Java classpa
Hi.
Le dim. 9 juin 2019 à 14:06, James Carman a écrit :
>
> On Sun, Jun 9, 2019 at 7:36 AM sebb 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 app
On Sun, Jun 9, 2019 at 7:36 AM sebb 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
On Sun, 9 Jun 2019 at 12:01, James Carman wrote:
>
> On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski 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 requi
On Sun, Jun 9, 2019 at 5:40 AM Gilles Sadowski 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
Hi.
Le jeu. 6 juin 2019 à 15:18, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 23:40, Gary Gregory 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
On Wed, 5 Jun 2019 at 23:40, Gary Gregory 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 exclu
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 y
Le mer. 5 juin 2019 à 23:14, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski wrote:
> >
> > Le mer. 5 juin 2019 à 17:57, James Carman 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 br
On June 5, 2019 at 12:16:33, Gilles Sadowski (gillese...@gmail.com) wrote:
Le mer. 5 juin 2019 à 17:57, James Carman 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
On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski wrote:
>
> Le mer. 5 juin 2019 à 17:57, James Carman 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 b
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
th
On Wed, Jun 5, 2019 at 12:16 PM Gilles Sadowski 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 in
Le mer. 5 juin 2019 à 17:57, James Carman 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 bas
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,
j
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 wrote:
> Le mer. 5 juin 2019 à 17:04, James Carman a
Le mer. 5 juin 2019 à 17:04, James Carman 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
[...]
-
T
Le mer. 5 juin 2019 à 17:02, James Carman 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
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
wrote:
> Le mer. 5 juin 2019 à 16:22, sebb a écrit :
> >
> > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:59, sebb a é
Wouldn’t you have a package collision between two different alpha releases?
On Wed, Jun 5, 2019 at 10:56 AM Gilles Sadowski
wrote:
> Le mer. 5 juin 2019 à 16:47, James Carman a
> écrit :
> >
> > Ok, what about 1.2?
>
> How is it different?
>
> Gilles
>
> >
> > On Wed, Jun 5, 2019 at 10:44 AM Gi
Le mer. 5 juin 2019 à 16:47, James Carman a écrit :
>
> Ok, what about 1.2?
How is it different?
Gilles
>
> On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski
> wrote:
>
> > Le mer. 5 juin 2019 à 16:18, James Carman a
> > écrit :
> > >
> > > What happens if/when you want to release a 2.0-alpha1
Le mer. 5 juin 2019 à 16:22, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski wrote:
> >
> > Le mer. 5 juin 2019 à 15:59, sebb a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > > > >
> > > >
Ok, what about 1.2?
On Wed, Jun 5, 2019 at 10:44 AM Gilles Sadowski
wrote:
> Le mer. 5 juin 2019 à 16:18, James Carman 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
Le mer. 5 juin 2019 à 16:18, James Carman 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 wrote:
>
> > Hello.
> >
>
Le mer. 5 juin 2019 à 16:18, Gary Gregory a écrit :
>
> On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski
> wrote:
>
> > Le mer. 5 juin 2019 à 15:59, sebb a écrit :
> > >
> > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski
> > wrote:
> > > >
> > > > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> >
On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski wrote:
>
> Le mer. 5 juin 2019 à 15:59, sebb a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > > >
> > > > I'm not sure what problem this is trying to solve.
> > > >
> >
On Wed, Jun 5, 2019 at 10:06 AM Gilles Sadowski
wrote:
> Le mer. 5 juin 2019 à 15:59, sebb a écrit :
> >
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski
> wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > > >
> > > > I'm not sure what problem this is trying to solve.
> > > >
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 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 c
Le mer. 5 juin 2019 à 16:04, Gary Gregory a écrit :
>
> On Wed, Jun 5, 2019 at 9:59 AM sebb wrote:
>
> > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> > >
> > > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > > >
> > > > I'm not sure what problem this is trying to solve.
> > > >
> > > >
Le mer. 5 juin 2019 à 15:59, sebb a écrit :
>
> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > >
> > > I'm not sure what problem this is trying to solve.
> > >
> > > How is it intended to use the facility?
> >
> > Ideally:
> > $ mv
On Wed, Jun 5, 2019 at 9:59 AM sebb wrote:
> On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
> >
> > Le mer. 5 juin 2019 à 15:18, sebb a écrit :
> > >
> > > I'm not sure what problem this is trying to solve.
> > >
> > > How is it intended to use the facility?
> >
> > Ideally:
> > $ mvn
On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski wrote:
>
> Le mer. 5 juin 2019 à 15:18, sebb 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
>
Le mer. 5 juin 2019 à 15:18, sebb 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 packag
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 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" ma
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 mar
38 matches
Mail list logo
