aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <gchart...@googlemail.com>
Subject Re: API/SPI Package versioning policy
Date Fri, 04 Jun 2010 07:55:37 GMT
I agree with Alasdair regarding the need for flexibility prior to
making 1.0 releases.  Some of the things being created are
experimental and need the flexibility to change.  Related to this and
implicit in my earlier comment is the notion that the bundles are
versioned and evolve independently.  So doing a 1.0 release should be
on a per component basis.

Regards, Graham.

On 3 June 2010 17:53, Alasdair Nottingham <not@apache.org> wrote:
> Hi,
>
> I agree we should use semantic versioning for a package. If a package does not change
then it's version does not change.
>
> For APIs aimed at application writers I thing we should aim to not make breaking changes,
but I'm less concerned about SPIs for integrators like Geronimo, but we should still avoid
breaking changes.
>
> I think until we do a 1.0 release though we can be more flexible, but we shouldn't meek
spurious breaking changes as it will inhibit uptake of the programming model.
>
> My 2 cents worth
> Alasdair
>
> Alasdair Nottingham
>
> On 3 Jun 2010, at 15:17, Graham Charters <gcharters@googlemail.com> wrote:
>
>> This is an important discussion to have.  I think we should adopt the
>> semantic versioning policy outlined in the OSGi Alliance whitepaper:
>> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf  .  This
>> includes guidelines on bundle versioning as well as packages.  I also
>> prefer trying to keep backward compatibility where practicable.
>>
>> Regards, Graham.
>>
>> On 3 June 2010 10:13, Timothy Ward <timothyjward@hotmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Based on some updates to the JPA container we are considering making some changes
to some SPI classes. Obviously this would mean that we needed to chagne the version of the
package, but I wanted to raise a discussion on the list about our versioning policy. Are we
trying to keep version to version compatability where possible, and if so, how hard? Are we
planning to change package versions every release (which appears to be what the pom files
say)?
>>>
>>> Similarly for bundle versions, if there are no changes to a bundle between releases
(for example if the JPA blueprint integration didn't change but the container added support
for weaving) then will the bundle version be changed anyway? If there are only minor bugfix
changes to the bundle will it still change major version on release?
>>>
>>>
>>> I know that my preference would be for a strict package versioning policy, and
trying to keep backward compatability wherever possible. I can't think of anything more annoying
than having to re-write or re-build plugins and extensions for every release. I'm less concerned
by bundle versions, but I would lean toward not changing them more often than necessary.
>>>
>>> What do people think?
>>>
>>> Regards,
>>>
>>> Tim
>>>
>>> _________________________________________________________________
>>> http://clk.atdmt.com/UKM/go/195013117/direct/01/
>>> We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
>

Mime
View raw message