ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: EA versioning
Date Tue, 08 Dec 2015 13:56:55 GMT
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 <cos@apache.org>:

> 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 <cos@apache.org>:
> > >
> > > > On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote:
> > > > > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > > > >
> > > > > 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
> > > >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message