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
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:
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
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
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
> 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
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
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
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
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
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
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
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
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
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.
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
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
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
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
19 matches
Mail list logo