EA versioning

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Branko Čibej
It was fun watching this thread. I don't even know what EA means, but I
have to wonder ... what's wrong with releasing 1.5.0-beta? Or does the
Java world need its own special terminology for yet another
well-established process? :)

-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Konstantin Boudnik-2
In reply to this post by yzhdanov
This is perhaps 12th or so project in my memory that tries to invent the wheel
to mark non-stable releases. Most notorious are Linux kernel and JDK. The
latter is particularly screwed-up, versioning wise. To date, people are call
it JDK1.7 and so on. Anyway...

After many bad ideas discussed, implemented, and thrown away, they always
converge to the good ol' semver. And I am sorry, but EA is as bad idea as the
alphas, betas, and gammas.

I am not going to explain why EA isn't going to work, because just a glance on
this thread shows that there were enough examples to prove the point. What I
want to suggest is simply this:
 - stick to semver
 - announce any particular version x.y.z you're pleased with as Alpha or Omega
   and move on
 - x.y.z+1 will be an improvement on x.y.z. At x.y.z+N once you're satisified
   with the quality of the release - call it stable and, if you wish, release
   it as some round number like X.Y.0

Done: easy and simple. Moving on.
  Cos

On Tue, Dec 01, 2015 at 12:35PM, Yakov Zhdanov wrote:

> Guys,
>
> When trying to release Apache Ignite 1.5.0 we came to conclusion that we
> had to proceed with EA version rather than with final release due to many
> reasons.
>
> I think that everyone understands the purposes of EA versions and the
> advantages that we gain if we establish this process in a proper way.
>
> Now I see the following points. Let's discuss and put results on our
> project wiki.
>
> 1. Complex features will be released only through EA process, but point
> and/or patch releases may omit this step.
>
> 2. The first EA (EA1?) build can be released when upcoming release gets
> 100% code/feature complete and it is verified that build/deployment
> procedures work and TC is in green state.
>
> 3. EA version names should be the following:
>
> * apache-ignite-X.X.X-EA1
> * apache-ignite-X.X.X-EA2
> * ...
> * apache-ignite-X.X.X-EA15
>
> Where X is a number. Index after EA makes ordering intuitive.
>
> 4. EA versions go through the same voting process as we have for release
> procedure now. E.g. apache-ignite-1.5.0-EA1-rc1 will be submitted and after
> approval "-rc1" part gets stripped.
>
> 5. I would prefer EA versions being available through maven. I know that
> there are different opinions on this and I know the reasoning for opinions,
> but from my standpoint this will save us from managing additional repos and
> make everything transparent.
>
>
> Thanks!
>
> --Yakov

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Konstantin Boudnik-2
In reply to this post by Raul Kripalani
On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > Raul, as an OSGI expert, do you confirm?
> >
>
> Yep, it was my proposal only to add "-final". Just to be clear, this is a
> Maven qualifier. The maven-bundle-plugin will translate the hyphen to a
> dot, for compatibility with OSGi.

For the die-hard fans of "-lksfdiuye" classifiers in Maven artifacts, I'd
suggest to check how well it has played for HBase. Hadoop been there as well -
they still are fighting the consequences of once thought to be a neat "-alpha"
idea. Seriously guys, this is gonna be mess, confusing the hell out of everybody.

Cos

> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Sergi
Cos and Brane,

This issue arised not from our feeling of beautiful, but from practical
reasons,
namely we need to conform existing Maven and OSGi version models at the
same time.

We did not invent Maven or OSGi, but if we want to play with them well,
we have to keep in mind their own quirks and bad design decisions,
when choosing how our versions will look like.

Cos,

JDK and Linux kernel are bad examples here exactly because
they were free to choose any good or bad versioning they want,
we are not that free.

Could you please clarify what exactly happened with HBase?
And why do you think we will have the same problems?

Sergi

2015-12-06 4:24 GMT+03:00 Konstantin Boudnik <[hidden email]>:

> On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <[hidden email]
> >
> > wrote:
> >
> > > Raul, as an OSGI expert, do you confirm?
> > >
> >
> > Yep, it was my proposal only to add "-final". Just to be clear, this is a
> > Maven qualifier. The maven-bundle-plugin will translate the hyphen to a
> > dot, for compatibility with OSGi.
>
> For the die-hard fans of "-lksfdiuye" classifiers in Maven artifacts, I'd
> suggest to check how well it has played for HBase. Hadoop been there as
> well -
> they still are fighting the consequences of once thought to be a neat
> "-alpha"
> idea. Seriously guys, this is gonna be mess, confusing the hell out of
> everybody.
>
> Cos
>
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
>
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Konstantin Boudnik-2
On Sun, Dec 06, 2015 at 11:30AM, Sergi Vladykin wrote:

> Cos and Brane,
>
> This issue arised not from our feeling of beautiful, but from practical
> reasons,
> namely we need to conform existing Maven and OSGi version models at the
> same time.
>
> We did not invent Maven or OSGi, but if we want to play with them well,
> we have to keep in mind their own quirks and bad design decisions,
> when choosing how our versions will look like.
Very true. However, both Maven and OSGi are supporting normal semver schema,
so the argument doesn't apply ;)

> Cos,
>
> JDK and Linux kernel are bad examples here exactly because
> they were free to choose any good or bad versioning they want,
> we are not that free.

We are free to stick to simver and don't make convoluted choices, that will
confuse the hell out of the users. I am seen 1.5.0-b1 getting released and I
already have no idea if it is better than 1.5.0 or worst. If the latter -
where's 1.5.0 then?

> Could you please clarify what exactly happened with HBase?
> And why do you think we will have the same problems?

Hbase used to have 0.98.16.1-hadoop2 and 0.98.16.1-hadoop1 classifiers to
distinguish between different versions of HDFS base. Considering that maven
classifiers are designed to differentiate between _types_ of artifacts, not
the platforms, hooking up to the hbase artifacts from different dependency
management systems were a royal PITA.

We'll have the same problem exactly because these are arbitrary choices and have
no similarities with anything else out there. The most effective engineering
principal is KISS: anything that goes against it will have a higher friction
with the users. Meaning more disoriented emails on the user@ list, more
frustration and incorrectly filed bug reports, reflecting in a lower
traction with future contributors.
 
Cheers,
  Cos

> 2015-12-06 4:24 GMT+03:00 Konstantin Boudnik <[hidden email]>:
>
> > On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> > > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <[hidden email]
> > >
> > > wrote:
> > >
> > > > Raul, as an OSGI expert, do you confirm?
> > > >
> > >
> > > Yep, it was my proposal only to add "-final". Just to be clear, this is a
> > > Maven qualifier. The maven-bundle-plugin will translate the hyphen to a
> > > dot, for compatibility with OSGi.
> >
> > For the die-hard fans of "-lksfdiuye" classifiers in Maven artifacts, I'd
> > suggest to check how well it has played for HBase. Hadoop been there as
> > well -
> > they still are fighting the consequences of once thought to be a neat
> > "-alpha"
> > idea. Seriously guys, this is gonna be mess, confusing the hell out of
> > everybody.
> >
> > Cos
> >
> > > *Raúl Kripalani*
> > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > > Messaging Engineer
> > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> >

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Weird releases [Was: EA versioning]

Konstantin Boudnik-2
Forking of the release schema conversation. I have noticed that official dist
    http://archive.apache.org/dist//ignite/

has 2.2.2-test version. Anyone knows why it is there?

Cos


signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Konstantin Boudnik-2
In reply to this post by Konstantin Boudnik-2
Oh, and not to say - JIRA would have to have a corresponding versions. Say
right now I see only 1.5 in JIRA and it has 161 unresolved bugs. However, the
-b1 release is already voted for and is almost official.

Cos

On Sun, Dec 06, 2015 at 03:11PM, Konstantin Boudnik wrote:

> On Sun, Dec 06, 2015 at 11:30AM, Sergi Vladykin wrote:
> > Cos and Brane,
> >
> > This issue arised not from our feeling of beautiful, but from practical
> > reasons,
> > namely we need to conform existing Maven and OSGi version models at the
> > same time.
> >
> > We did not invent Maven or OSGi, but if we want to play with them well,
> > we have to keep in mind their own quirks and bad design decisions,
> > when choosing how our versions will look like.
>
> Very true. However, both Maven and OSGi are supporting normal semver schema,
> so the argument doesn't apply ;)
>
> > Cos,
> >
> > JDK and Linux kernel are bad examples here exactly because
> > they were free to choose any good or bad versioning they want,
> > we are not that free.
>
> We are free to stick to simver and don't make convoluted choices, that will
> confuse the hell out of the users. I am seen 1.5.0-b1 getting released and I
> already have no idea if it is better than 1.5.0 or worst. If the latter -
> where's 1.5.0 then?
>
> > Could you please clarify what exactly happened with HBase?
> > And why do you think we will have the same problems?
>
> Hbase used to have 0.98.16.1-hadoop2 and 0.98.16.1-hadoop1 classifiers to
> distinguish between different versions of HDFS base. Considering that maven
> classifiers are designed to differentiate between _types_ of artifacts, not
> the platforms, hooking up to the hbase artifacts from different dependency
> management systems were a royal PITA.
>
> We'll have the same problem exactly because these are arbitrary choices and have
> no similarities with anything else out there. The most effective engineering
> principal is KISS: anything that goes against it will have a higher friction
> with the users. Meaning more disoriented emails on the user@ list, more
> frustration and incorrectly filed bug reports, reflecting in a lower
> traction with future contributors.
>  
> Cheers,
>   Cos
>
> > 2015-12-06 4:24 GMT+03:00 Konstantin Boudnik <[hidden email]>:
> >
> > > On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> > > > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <[hidden email]
> > > >
> > > > wrote:
> > > >
> > > > > Raul, as an OSGI expert, do you confirm?
> > > > >
> > > >
> > > > Yep, it was my proposal only to add "-final". Just to be clear, this is a
> > > > Maven qualifier. The maven-bundle-plugin will translate the hyphen to a
> > > > dot, for compatibility with OSGi.
> > >
> > > For the die-hard fans of "-lksfdiuye" classifiers in Maven artifacts, I'd
> > > suggest to check how well it has played for HBase. Hadoop been there as
> > > well -
> > > they still are fighting the consequences of once thought to be a neat
> > > "-alpha"
> > > idea. Seriously guys, this is gonna be mess, confusing the hell out of
> > > everybody.
> > >
> > > Cos
> > >
> > > > *Raúl Kripalani*
> > > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > > > Messaging Engineer
> > > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > > > http://blog.raulkr.net | twitter: @raulvk
> > >


signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Weird releases [Was: EA versioning]

Anton Vinogradov
In reply to this post by Konstantin Boudnik-2
It's a test release.
I have no clue why it's located at archive dist.
It should be removed.

Does anybody know how to remove it?

On Mon, Dec 7, 2015 at 7:18 AM, Konstantin Boudnik <[hidden email]> wrote:

> Forking of the release schema conversation. I have noticed that official
> dist
>     http://archive.apache.org/dist//ignite/
>
> has 2.2.2-test version. Anyone knows why it is there?
>
> Cos
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Weird releases [Was: EA versioning]

Konstantin Boudnik-2
On Mon, Dec 07, 2015 at 12:56PM, Anton Vinogradov wrote:
> It's a test release.
> I have no clue why it's located at archive dist.
> It should be removed.
>
> Does anybody know how to remove it?

I think the only way to remove something from archive is by asking infra@ to
do so. Either by a ticket or via hipchat channel.

Cos

> On Mon, Dec 7, 2015 at 7:18 AM, Konstantin Boudnik <[hidden email]> wrote:
>
> > Forking of the release schema conversation. I have noticed that official
> > dist
> >     http://archive.apache.org/dist//ignite/
> >
> > has 2.2.2-test version. Anyone knows why it is there?
> >
> > Cos
> >
> >

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Sergi
In reply to this post by Konstantin Boudnik-2
Cos,

I think you are right, probably we have to release 1.5.0-b1 then stable
bug-fix versions will be 1.5.1, 1.5.2...
And then next release from master should be 1.6.0. Yes, this should work
and then we will not need
*final *qualifier.

Sergi


2015-12-07 7:23 GMT+03:00 Konstantin Boudnik <[hidden email]>:

> Oh, and not to say - JIRA would have to have a corresponding versions. Say
> right now I see only 1.5 in JIRA and it has 161 unresolved bugs. However,
> the
> -b1 release is already voted for and is almost official.
>
> Cos
>
> On Sun, Dec 06, 2015 at 03:11PM, Konstantin Boudnik wrote:
> > On Sun, Dec 06, 2015 at 11:30AM, Sergi Vladykin wrote:
> > > Cos and Brane,
> > >
> > > This issue arised not from our feeling of beautiful, but from practical
> > > reasons,
> > > namely we need to conform existing Maven and OSGi version models at the
> > > same time.
> > >
> > > We did not invent Maven or OSGi, but if we want to play with them well,
> > > we have to keep in mind their own quirks and bad design decisions,
> > > when choosing how our versions will look like.
> >
> > Very true. However, both Maven and OSGi are supporting normal semver
> schema,
> > so the argument doesn't apply ;)
> >
> > > Cos,
> > >
> > > JDK and Linux kernel are bad examples here exactly because
> > > they were free to choose any good or bad versioning they want,
> > > we are not that free.
> >
> > We are free to stick to simver and don't make convoluted choices, that
> will
> > confuse the hell out of the users. I am seen 1.5.0-b1 getting released
> and I
> > already have no idea if it is better than 1.5.0 or worst. If the latter -
> > where's 1.5.0 then?
> >
> > > Could you please clarify what exactly happened with HBase?
> > > And why do you think we will have the same problems?
> >
> > Hbase used to have 0.98.16.1-hadoop2 and 0.98.16.1-hadoop1 classifiers to
> > distinguish between different versions of HDFS base. Considering that
> maven
> > classifiers are designed to differentiate between _types_ of artifacts,
> not
> > the platforms, hooking up to the hbase artifacts from different
> dependency
> > management systems were a royal PITA.
> >
> > We'll have the same problem exactly because these are arbitrary choices
> and have
> > no similarities with anything else out there. The most effective
> engineering
> > principal is KISS: anything that goes against it will have a higher
> friction
> > with the users. Meaning more disoriented emails on the user@ list, more
> > frustration and incorrectly filed bug reports, reflecting in a lower
> > traction with future contributors.
> >
> > Cheers,
> >   Cos
> >
> > > 2015-12-06 4:24 GMT+03:00 Konstantin Boudnik <[hidden email]>:
> > >
> > > > On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> > > > > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <
> [hidden email]
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Raul, as an OSGI expert, do you confirm?
> > > > > >
> > > > >
> > > > > Yep, it was my proposal only to add "-final". Just to be clear,
> this is a
> > > > > Maven qualifier. The maven-bundle-plugin will translate the hyphen
> to a
> > > > > dot, for compatibility with OSGi.
> > > >
> > > > For the die-hard fans of "-lksfdiuye" classifiers in Maven
> artifacts, I'd
> > > > suggest to check how well it has played for HBase. Hadoop been there
> as
> > > > well -
> > > > they still are fighting the consequences of once thought to be a neat
> > > > "-alpha"
> > > > idea. Seriously guys, this is gonna be mess, confusing the hell out
> of
> > > > everybody.
> > > >
> > > > Cos
> > > >
> > > > > *Raúl Kripalani*
> > > > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
> Data and
> > > > > Messaging Engineer
> > > > > http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
> > > > > http://blog.raulkr.net | twitter: @raulvk
> > > >
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: EA versioning

Konstantin Boudnik-2
Yup! It will remove any uncertainties about version sequence. And if anything
extra needs to be said about the quality of the release, it should be
communicated via documentation, README, releaseNotes, or else.

Thanks
  Cos

On Tue, Dec 08, 2015 at 04:56PM, Sergi Vladykin wrote:

> Cos,
>
> I think you are right, probably we have to release 1.5.0-b1 then stable
> bug-fix versions will be 1.5.1, 1.5.2...
> And then next release from master should be 1.6.0. Yes, this should work
> and then we will not need
> *final *qualifier.
>
> Sergi
>
>
> 2015-12-07 7:23 GMT+03:00 Konstantin Boudnik <[hidden email]>:
>
> > Oh, and not to say - JIRA would have to have a corresponding versions. Say
> > right now I see only 1.5 in JIRA and it has 161 unresolved bugs. However,
> > the
> > -b1 release is already voted for and is almost official.
> >
> > Cos
> >
> > On Sun, Dec 06, 2015 at 03:11PM, Konstantin Boudnik wrote:
> > > On Sun, Dec 06, 2015 at 11:30AM, Sergi Vladykin wrote:
> > > > Cos and Brane,
> > > >
> > > > This issue arised not from our feeling of beautiful, but from practical
> > > > reasons,
> > > > namely we need to conform existing Maven and OSGi version models at the
> > > > same time.
> > > >
> > > > We did not invent Maven or OSGi, but if we want to play with them well,
> > > > we have to keep in mind their own quirks and bad design decisions,
> > > > when choosing how our versions will look like.
> > >
> > > Very true. However, both Maven and OSGi are supporting normal semver
> > schema,
> > > so the argument doesn't apply ;)
> > >
> > > > Cos,
> > > >
> > > > JDK and Linux kernel are bad examples here exactly because
> > > > they were free to choose any good or bad versioning they want,
> > > > we are not that free.
> > >
> > > We are free to stick to simver and don't make convoluted choices, that
> > will
> > > confuse the hell out of the users. I am seen 1.5.0-b1 getting released
> > and I
> > > already have no idea if it is better than 1.5.0 or worst. If the latter -
> > > where's 1.5.0 then?
> > >
> > > > Could you please clarify what exactly happened with HBase?
> > > > And why do you think we will have the same problems?
> > >
> > > Hbase used to have 0.98.16.1-hadoop2 and 0.98.16.1-hadoop1 classifiers to
> > > distinguish between different versions of HDFS base. Considering that
> > maven
> > > classifiers are designed to differentiate between _types_ of artifacts,
> > not
> > > the platforms, hooking up to the hbase artifacts from different
> > dependency
> > > management systems were a royal PITA.
> > >
> > > We'll have the same problem exactly because these are arbitrary choices
> > and have
> > > no similarities with anything else out there. The most effective
> > engineering
> > > principal is KISS: anything that goes against it will have a higher
> > friction
> > > with the users. Meaning more disoriented emails on the user@ list, more
> > > frustration and incorrectly filed bug reports, reflecting in a lower
> > > traction with future contributors.
> > >
> > > Cheers,
> > >   Cos
> > >
> > > > 2015-12-06 4:24 GMT+03:00 Konstantin Boudnik <[hidden email]>:
> > > >
> > > > > On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> > > > > > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <
> > [hidden email]
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Raul, as an OSGI expert, do you confirm?
> > > > > > >
> > > > > >
> > > > > > Yep, it was my proposal only to add "-final". Just to be clear,
> > this is a
> > > > > > Maven qualifier. The maven-bundle-plugin will translate the hyphen
> > to a
> > > > > > dot, for compatibility with OSGi.
> > > > >
> > > > > For the die-hard fans of "-lksfdiuye" classifiers in Maven
> > artifacts, I'd
> > > > > suggest to check how well it has played for HBase. Hadoop been there
> > as
> > > > > well -
> > > > > they still are fighting the consequences of once thought to be a neat
> > > > > "-alpha"
> > > > > idea. Seriously guys, this is gonna be mess, confusing the hell out
> > of
> > > > > everybody.
> > > > >
> > > > > Cos
> > > > >
> > > > > > *Raúl Kripalani*
> > > > > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
> > Data and
> > > > > > Messaging Engineer
> > > > > > http://about.me/raulkripalani |
> > http://www.linkedin.com/in/raulkripalani
> > > > > > http://blog.raulkr.net | twitter: @raulvk
> > > > >
> >
> >
> >

signature.asc (237 bytes) Download Attachment
123