You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2017/08/13 08:04:06 UTC
Project versioning and OSGi
Hi guys,
when dealing with OSGi, we are likely to face some issue with teh
version scheme we use :
- maven makes it so 1.0.0 > 1.0.0-Mn and 1.0.0 > 1.0.0-RCn (we use M for
milestone and RC for release candidates)
- OSGI is purely incremental, and use a X.Y.Z.qualifier scheme, where
the qualifier is compared using a String comparison.
- OSGi does not accept '-' in between the version numbers (like
2.0.0-M1, it should be 2.0.0.M1)
The issue with our scheme is that if we cut a release and call it 2.0.0,
it will always be seen as inferior to any milstone of RC we created
beforhand.
I suggest we modify teh wy we name our versions in a way that is not
intrusive :
- release will not be plain numbers, like 2.0.0, but 2.0.0.GA
- Milestone will be named AM (A does not stand for anything, it's just
used to make sure it's lower than CR and GA)
- Release Candidate CR (instead of RC). The rational is that AMn < CRn <
GA, so 2.0.0.AM3 < 2.0.0.CR1 < 2.0.0.GA. It's a convention, and I know
it's a hack...
- Get rid of '-' and use a '.' instead.
Those are minimal changes that would not have a huge impact on teh way
we work, I think.
Thoughts ?
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: Project versioning and OSGi
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 14/08/2017 à 22:36, Jesse McConnell a écrit :
> Something we have learned with Jetty and our adoption of osgi versioning is
> that most anything beyond normal versioning really confuses people. We
> have had an embarrassing amount of people think a M# release (supposedly
> milestone) was suitable for production and that our actual releases
> X.Y.Z.v20170814 looked too like a timestamp and they thought it was some
> sort of maven snapshot. I don't even want to think what people think RC#
> means. Personally I don't see how this sort of confusion is possible, but
> I saw you folks messing around with osgi versioning and figured I would
> chime in with some advice to keep it as simple as possible and as much as
> possible remove any doubt as to what stage of development an artifact is.
> Anything outside of the normal X.Y.Z and people seem to get easily confused.
For a decade, we have released packages with milestones and release
candidates... What I see is that people always use the latest version,
be it a RC or a M, and as we haven't released a final version of
ApacheDS for more than 7 years (yeah, pretty bad, isn'tit ? ;/), I don't
think it would make a lot of difference to drop all those RC/M stuff.
I was convinced that going for M and RC was teh roght move, but now it
seems a bit old fashionned, with project like Vhrome or FF releasing new
version every now and then.
I do think we might also want to stop releasing M and RC and switch to
something simpler, as suggested (ie, x.y.z, period). That's more than
enough. However, I would suggest doing so for new releases that don't
have *yet* any release, like LDAP API. Ie, LDAP API 2.0.0 would be the
next release, because we only have a 1.0.0, but ApacheDS is already
using 2.0.0-XXX for years, so it's hard to go for a 2.0.0, because it
would break some code (see later comment).
For a post 2.0.0.GA ApacheDS release, I'd suggest to go for 3.0.0 and to
drop any M and RC (or AM and CR...)
>
> And avoid P2 repositories unless you have some arcane requirement.
Sadly, we can't : Studio is eclipse based, and heavily depends on p2.
Thanks for the insights, Jesse.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: Project versioning and OSGi
Posted by Jesse McConnell <je...@gmail.com>.
Something we have learned with Jetty and our adoption of osgi versioning is
that most anything beyond normal versioning really confuses people. We
have had an embarrassing amount of people think a M# release (supposedly
milestone) was suitable for production and that our actual releases
X.Y.Z.v20170814 looked too like a timestamp and they thought it was some
sort of maven snapshot. I don't even want to think what people think RC#
means. Personally I don't see how this sort of confusion is possible, but
I saw you folks messing around with osgi versioning and figured I would
chime in with some advice to keep it as simple as possible and as much as
possible remove any doubt as to what stage of development an artifact is.
Anything outside of the normal X.Y.Z and people seem to get easily confused.
And avoid P2 repositories unless you have some arcane requirement.
cheers,
Jesse
--
jesse mcconnell
jesse.mcconnell@gmail.com
On Mon, Aug 14, 2017 at 10:27 AM, Shawn McKinney <sm...@apache.org>
wrote:
>
> > On Aug 13, 2017, at 3:04 AM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> >
> > The issue with our scheme is that if we cut a release and call it 2.0.0,
> > it will always be seen as inferior to any milstone of RC we created
> > beforhand.
> >
>
> How does this issue present itself as a problem? What are the
> ramifications of this problem?
>
> What I’m asking, is this a problem (only) with OSGI related processes, or
> does it extend outside to things like maven, git, or human-based reasoning?
>
> > I suggest we modify teh wy we name our versions in a way that is not
> > intrusive :
> >
> > - release will not be plain numbers, like 2.0.0, but 2.0.0.GA
> >
> > - Milestone will be named AM (A does not stand for anything, it's just
> > used to make sure it's lower than CR and GA)
> >
> > - Release Candidate CR (instead of RC). The rational is that AMn < CRn <
> > GA, so 2.0.0.AM3 < 2.0.0.CR1 < 2.0.0.GA. It's a convention, and I kno
>
> The current versioning scheme is simple, intuitive and fits fortress’
> needs quite well. Must we change as well?
>
> Thanks,
> Shawn
Re: Project versioning and OSGi
Posted by Shawn McKinney <sm...@apache.org>.
> On Aug 13, 2017, at 3:04 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>
> The issue with our scheme is that if we cut a release and call it 2.0.0,
> it will always be seen as inferior to any milstone of RC we created
> beforhand.
>
How does this issue present itself as a problem? What are the ramifications of this problem?
What I’m asking, is this a problem (only) with OSGI related processes, or does it extend outside to things like maven, git, or human-based reasoning?
> I suggest we modify teh wy we name our versions in a way that is not
> intrusive :
>
> - release will not be plain numbers, like 2.0.0, but 2.0.0.GA
>
> - Milestone will be named AM (A does not stand for anything, it's just
> used to make sure it's lower than CR and GA)
>
> - Release Candidate CR (instead of RC). The rational is that AMn < CRn <
> GA, so 2.0.0.AM3 < 2.0.0.CR1 < 2.0.0.GA. It's a convention, and I kno
The current versioning scheme is simple, intuitive and fits fortress’ needs quite well. Must we change as well?
Thanks,
Shawn
Re: Project versioning and OSGi
Posted by Lucas Theisen <lu...@pastdev.com>.
My 10 cents would be: just drop the suffix altogether. Let the patch just
increment. I don't see a reason that we shouldn't just be 2.0.25. I have
been using milestones in production for 7 years now...
That said, I think there are many other conventions out there (.FINAL
hibernate, .RELEASE spring, .GA Liferay, ...) and you suggestion is as good
as any
On Aug 13, 2017 6:47 AM, "Stefan Seelmann" <ma...@stefan-seelmann.de> wrote:
> On 08/13/2017 10:04 AM, Emmanuel Lécharny wrote:
> > Hi guys,
> >
> >
> > when dealing with OSGi, we are likely to face some issue with teh
> > version scheme we use :
> >
> > - maven makes it so 1.0.0 > 1.0.0-Mn and 1.0.0 > 1.0.0-RCn (we use M for
> > milestone and RC for release candidates)
> >
> > - OSGI is purely incremental, and use a X.Y.Z.qualifier scheme, where
> > the qualifier is compared using a String comparison.
> >
> > - OSGi does not accept '-' in between the version numbers (like
> > 2.0.0-M1, it should be 2.0.0.M1)
> >
> >
> > The issue with our scheme is that if we cut a release and call it 2.0.0,
> > it will always be seen as inferior to any milstone of RC we created
> > beforhand.
>
> My pragmatic answer: just use 2.0.1 for the first non-M and non-RC release.
>
> > I suggest we modify teh wy we name our versions in a way that is not
> > intrusive :
> >
> > - release will not be plain numbers, like 2.0.0, but 2.0.0.GA
> >
> > - Milestone will be named AM (A does not stand for anything, it's just
> > used to make sure it's lower than CR and GA)
> >
> > - Release Candidate CR (instead of RC). The rational is that AMn < CRn <
> > GA, so 2.0.0.AM3 < 2.0.0.CR1 < 2.0.0.GA. It's a convention, and I know
> > it's a hack...
> >
> > - Get rid of '-' and use a '.' instead.
>
> Fine for me if it helps. Howerver for ApacheDS 2.0.0 this is already too
> late, because we alrady released 2.0.0.M24, right?
>
> Stefan
>
Re: Project versioning and OSGi
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 13/08/2017 à 12:46, Stefan Seelmann a écrit :
> On 08/13/2017 10:04 AM, Emmanuel Lécharny wrote:
>> Hi guys,
>>
>>
>> when dealing with OSGi, we are likely to face some issue with teh
>> version scheme we use :
>>
>> - maven makes it so 1.0.0 > 1.0.0-Mn and 1.0.0 > 1.0.0-RCn (we use M for
>> milestone and RC for release candidates)
>>
>> - OSGI is purely incremental, and use a X.Y.Z.qualifier scheme, where
>> the qualifier is compared using a String comparison.
>>
>> - OSGi does not accept '-' in between the version numbers (like
>> 2.0.0-M1, it should be 2.0.0.M1)
>>
>>
>> The issue with our scheme is that if we cut a release and call it 2.0.0,
>> it will always be seen as inferior to any milstone of RC we created
>> beforhand.
> My pragmatic answer: just use 2.0.1 for the first non-M and non-RC release.
That's not exactly working ;-) Or we should use 1.9.9.Mn then 1.9.9.RCn
just before going to a 2.0.0 ! (Note that is also an option, but it may
be a bit more terse...)
>
>> I suggest we modify teh wy we name our versions in a way that is not
>> intrusive :
>>
>> - release will not be plain numbers, like 2.0.0, but 2.0.0.GA
>>
>> - Milestone will be named AM (A does not stand for anything, it's just
>> used to make sure it's lower than CR and GA)
>>
>> - Release Candidate CR (instead of RC). The rational is that AMn < CRn <
>> GA, so 2.0.0.AM3 < 2.0.0.CR1 < 2.0.0.GA. It's a convention, and I know
>> it's a hack...
>>
>> - Get rid of '-' and use a '.' instead.
> Fine for me if it helps. Howerver for ApacheDS 2.0.0 this is already too
> late, because we alrady released 2.0.0.M24, right?
I used 2.0.0 for the LDAP API, but it works for any version except
ApacheDS which will released as 2.0.0, sadly. Or we can name it 2.0.0.Z
(to be sure it's the last iteration...)
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: Project versioning and OSGi
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 08/13/2017 10:04 AM, Emmanuel Lécharny wrote:
> Hi guys,
>
>
> when dealing with OSGi, we are likely to face some issue with teh
> version scheme we use :
>
> - maven makes it so 1.0.0 > 1.0.0-Mn and 1.0.0 > 1.0.0-RCn (we use M for
> milestone and RC for release candidates)
>
> - OSGI is purely incremental, and use a X.Y.Z.qualifier scheme, where
> the qualifier is compared using a String comparison.
>
> - OSGi does not accept '-' in between the version numbers (like
> 2.0.0-M1, it should be 2.0.0.M1)
>
>
> The issue with our scheme is that if we cut a release and call it 2.0.0,
> it will always be seen as inferior to any milstone of RC we created
> beforhand.
My pragmatic answer: just use 2.0.1 for the first non-M and non-RC release.
> I suggest we modify teh wy we name our versions in a way that is not
> intrusive :
>
> - release will not be plain numbers, like 2.0.0, but 2.0.0.GA
>
> - Milestone will be named AM (A does not stand for anything, it's just
> used to make sure it's lower than CR and GA)
>
> - Release Candidate CR (instead of RC). The rational is that AMn < CRn <
> GA, so 2.0.0.AM3 < 2.0.0.CR1 < 2.0.0.GA. It's a convention, and I know
> it's a hack...
>
> - Get rid of '-' and use a '.' instead.
Fine for me if it helps. Howerver for ApacheDS 2.0.0 this is already too
late, because we alrady released 2.0.0.M24, right?
Stefan