Re: Releases, Continuous Delivery and the Future

2015-01-04 Thread Jason van Zyl
OSGi is major.minor.micro.qualifier[1] which is essentially semver[2] with a qualifier where the qualifier in both cases is some element like a build number or time. I think the first three elements can become definitively useful employing something akin to the Eclipse API tooling (only works fo

Re: Releases, Continuous Delivery and the Future

2015-01-04 Thread William Ferguson
Is there any reason not to use x.y.NN? The z qualifier is really used for fixes to x.y. So I can't see how it is different to a released x.y.NN This would then keep the version numbers compatible with OSGi versioning. And do we really want a fourth qualifier? William ᐧ On Sat, Jan 3, 2015 at 8:

Re: Releases, Continuous Delivery and the Future

2015-01-03 Thread Hervé BOUTEMY
IMHO, we should just make "lazy RC" ie: 1. prepare it like a release (with a tag in SCM) 2. but no VOTE: just a one week TEST period, to let people discover and report if there is some issue once we have one testing week, we can do a classical x.y.z release: there are few chances the release wil

Re: Releases, Continuous Delivery and the Future

2015-01-03 Thread Hervé BOUTEMY
Le vendredi 2 janvier 2015 10:31:52 Baptiste Mathus a écrit : > Well, I for one find the x.y.z-nn somehow unusual. I'd prefer something > simple like x.y.z and I don't give a f*ck if some numbers are skipped. > > +1 with Stephen: I've never seen someone complain about missing versions > neither on

Re: Releases, Continuous Delivery and the Future

2015-01-02 Thread Baptiste Mathus
Well, I for one find the x.y.z-nn somehow unusual. I'd prefer something simple like x.y.z and I don't give a f*ck if some numbers are skipped. +1 with Stephen: I've never seen someone complain about missing versions neither on ML nor IRL. Sure, I suppose people might wonder where the 4.x went if t

Re: Releases, Continuous Delivery and the Future

2014-12-28 Thread Brian E. Fox
> On Dec 14, 2014, at 8:29 PM, Jason van Zyl wrote: > > What we want is a form of continuous delivery where a version like 3.2.4 is > the version that we call it to the outside world (some refer to it as the > marketing version) and the qualifier changes from build to build so we have: > > 3

Re: Releases, Continuous Delivery and the Future

2014-12-17 Thread Dennis Lundberg
For JIRA there is an easier way to handle this: you rename the version(s) in JIRA. If 3.2.4 fails, rename it to 3.2.5. Additionally if there are more future patch versions in JIRA, then they need to be renamed first. If 3.2.4 fails , and in JIRA we have 3.2.4, 3.2.5 and 3.2.6, then we end up wit

Re: Releases, Continuous Delivery and the Future

2014-12-16 Thread Robert Scholte
Great wording, although I really hope that nobody read 3.1.1 as 311, as if 3.1.2 (or 312) must be the next version. 3.2.0 was very valid. We're talking about major.minor.bugfix, each having its own value. Just like people saying that 0.99 would be the final draft. Why? 0.100 (or 0.999 if you

Re: Releases, Continuous Delivery and the Future

2014-12-15 Thread Paul Benedict
Jason, thanks for taking the time to write this up. It is a good read. One extra tidbit I'd like to discussion is this. When I recommended we burn the version when the vote/build fails, I wasn't expecting we would move the fixed issues to the new version. Let's not do that. I find that confusing b

RE: Releases, Continuous Delivery and the Future

2014-12-15 Thread Robert Patrick
To: Maven Developers List Subject: Re: Releases, Continuous Delivery and the Future You're not missing anything. The integration we've written essentially replaces much of the internal resolution mechanism with support on the repository side. We currently do not use SNAPSHOTs and we do use

Re: Releases, Continuous Delivery and the Future

2014-12-15 Thread Jason van Zyl
You're not missing anything. The integration we've written essentially replaces much of the internal resolution mechanism with support on the repository side. We currently do not use SNAPSHOTs and we do use ranges for a team of 1500+ developers. It will all be open source but we're not ready to

Re: Releases, Continuous Delivery and the Future

2014-12-15 Thread Jason van Zyl
On Dec 15, 2014, at 1:49 AM, Kristian Rosenvold wrote: > I somehow think we need to decide if we want to change anything :) > We certainly don't have to. I'm describing a system that's been implemented and it's working but I'm not expecting as a certainty that it's integrated here. I believ

Re: Releases, Continuous Delivery and the Future

2014-12-15 Thread Robert Patrick
Sorry for the noise and maybe I am just being stupid but... This is a constant source of pain for us as Maven users when we do not use snapshots. The real problem is that once you go down his path, Maven seems to really only have two choices when you set your dependency version to 2.5.3: 1.) i

Re: Releases, Continuous Delivery and the Future

2014-12-15 Thread Stephen Connolly
On 15 December 2014 at 01:29, Jason van Zyl wrote: > > Hi, > > The discussion keeps resurfacing about how we deal with failed releases so > I'll summarize how I think it should ultimately be done as a starting point. > > I'll go over the cases we've encountered thus far: > > 1) The user case prefe

Re: Releases, Continuous Delivery and the Future

2014-12-14 Thread Kristian Rosenvold
I somehow think we need to decide if we want to change anything :) Without changing anything there seem to be only "so" many approaches out there, this is well known territory. While initially confusing, jetty's 9.2.3.v20140905 approach is quite good. I assume they might have had a failing " 9.2.

Re: Releases, Continuous Delivery and the Future

2014-12-14 Thread Fred Cooke
OK, well, classifiers works for me, then. It certainly seems like SNAPSHOTs are not the go-forward plan, at least, without your fix. Is it true that you can't use 4 part versions with Maven without confusing some logic that is hard coded to look for 1.2.3 rather than N.N+1.N+2N+M ? If not tru

Re: Releases, Continuous Delivery and the Future

2014-12-14 Thread Jason van Zyl
A further definition of a qualifier is that it applies to all artifacts in a multi-module project (MMP). Unfortunately, at present, SNAPSHOTs are fundamentally flawed in that all artifacts produced in an MMP do not get the same timestamp. Each artifact gets its own which makes it impossible to r

Re: Releases, Continuous Delivery and the Future

2014-12-14 Thread Fred Cooke
Thank /***, finally some movement in the right direction! :-D Please also try to remember that EVERY single one of your "users" is a *developer* and should comprehend that a version is an arbitrary label on a piece of software to be used to uniquely identify it. If not, they should be educated

Releases, Continuous Delivery and the Future

2014-12-14 Thread Jason van Zyl
Hi, The discussion keeps resurfacing about how we deal with failed releases so I'll summarize how I think it should ultimately be done as a starting point. I'll go over the cases we've encountered thus far: 1) The user case prefers non-disjunct sets of releases, or from our PoV re-used version