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 <c...@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 <c...@apache.org>: > > > > > > > > > On Tue, Dec 01, 2015 at 07:18PM, Raul Kripalani wrote: > > > > > > On Tue, Dec 1, 2015 at 7:15 PM, Dmitriy Setrakyan < > > dsetrak...@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 > > > > > > > > > > >
signature.asc
Description: Digital signature
