You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/02/04 14:44:07 UTC

Release / verisoning requirements (was Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/)

On Fri, Feb 4, 2011 at 14:11, zoe slattery <zo...@gmail.com> wrote:
> On 04/02/2011 12:33, Guillaume Nodet wrote:
>>
>> Afaik, the maven release plugin can actually release several maven
>> projects at the same time each one having its own release number.
>> Meaning when you release a project consisting of several maven
>> subprojects, each one can have its own release version (whether or not
>> that's desirable is a completely different problem).
>
> Yes, I think it can.
>>
>> On the osgi versioning problem, I'm not sure we have to assume that
>> the version number of the package is the same as the one for the
>> bundle, so the fact you need to specify a range isn't related to the
>> release process.
>
> No - it's part of the development process. I think it _is_ assumed by what
> is in our default parent pom at the moment.
>>
>> The maven bundle plugin can automatically generate a
>> range based on the information it finds, so here again, it's related
>> to the package versioning, not the bundle versioning.  Please remember
>> that the semantic associated to the version in OSGi is at the package
>> level, not the bundle level.
>
> Understood.
>>
>> Last, I'm not sure we're going into the right direction.  I think
>> those decisions should not be bound to technical considerations so
>> early in the process.
>
> I don't think we are going in any particular direction at the moment - or at
> least I'm not. The reason for the experimental branch was to
> try and understand more about what we would have to do to get semantic
> versioning correct for both bundles and packages.
>>
>> I'm quite sure we have a lot of freedom in choosing how we want to
>> version things and release them.
>>
>> Maybe we should start by stating by agreeing on what we'd like first.
>
> Before we go in any particular direction we must agree, that's true. Is it
> possible to agree with these goals now:
>
> 1) As an OSGi project we must demonstrate best practice in our use of
> semantic versioning at bundle and package level

Agreed, though I don't think there's much semantic implied at the bundle level.

> 2) A build and release process which allows us to do
>    (a) A release of everything in one go with associated samples which are
> therefore guaranteed to work together
>    (b) Release by module - with the correctly versioned bundles of
> sub-modules
>    (c) To avoid having to do release by sub-module (eg not having to do 17
> separate release steps for blueprint)

Well, those are side issues imho and I think they conflict with the
requirements I propose below.

I'd rather have the following requirements:
  1. correct osgi semantic versioning
  2. a release must have a buildable source distribution (that's
really an asf requirement, as the source distribution *is* really the
release from an asf pov)
  3. a release should have some release notes listing the changes in
that release
  4. a release must be publicly announced
  5. users should have an easy way to download the bundles needed for
a given component (blueprint, etc...)
  6. easy tagging / branching mechanism

I think #1 implies that the package versioning should not be tied to
the bundle version, as uber-bundles will definitely contain several
different versions for their included packages (and that's already the
case when we ship an osgi spec package for example.

#2 is an ASF requirement afaik.  Felix has a per-bundle release policy
and each bundle comes with its own buildable distribution, see
http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.fileinstall/3.1.6/org.apache.felix.fileinstall-3.1.6-project.tar.gz
for example.   I'm really convinced with a per-bundle release policy
for Aries

#3 is really important for our users and I think we need to leverage
JIRA for that.  Meaning for each *release* (being per-bundle,
per-component, or per-aries), we need to have a changelog either in
svn or on the website. And it need to be consistent, i.e. if we allow
per-bundle releases, all release notes should be per-bundle, else
there's no real way to find your way around.

#4 is a brainer if we want to actually create a community for our users

#5 is important for beginners and I'd also say that for downstream
users, we want to have an easy way to know which bundles are supposed
to work together (and tested).  I don't necessarily imply we need a
zip that the user can download, a web page stating all the
(up-to-date) dependencies for a given component could be sufficient.

#6 i think that can be argued, but for maintenance branches, tags and
all, I think it's way easier if we have a trunk/tags/branch setup per
release-cycle, else it becomes really difficult to follow.  For the
past releases, we had a per-component release cycle, but not a
per-component trunk/tags/branch set up.  I think that's not the best
option.   Such a set up would also allow us to create predicatable
maintenance branches.  For example, there's no easy way to find where
the application-0.2.1 release which is under way come from (well,
currently, given the very low number of releases, it's not very
difficult, but if we version components independantly, how will you
call the branch ?)

Feedback welcome !

> Z
>>
>> On Fri, Feb 4, 2011 at 13:18, zoe slattery<zo...@gmail.com>  wrote:
>>>
>>> On 03/02/2011 22:28, Guillaume Nodet wrote:
>>>>
>>>> What kind of experiments do you have in mind ?
>>>
>>> Probably this is more to do with my understanding (or lack of) of the way
>>> in
>>> which the current maven
>>> build specifies versions and how the release process deals with them.
>>>>
>>>> I'm not sure to actually understand how the release process will be
>>>> different if we release everyting in one go, component by component,
>>>> or bundle by bundle.  At the end, it always comes down to the same
>>>> steps: updating pom dependencies, mvn release:prepare release:perform,
>>>> updating jira, vote, updating the web site, annoucement.
>>>> The obvious different will be at which level you run the command from,
>>>> but apart from that, I kinda fail to see what kind of impact it would
>>>> have.
>>>
>>> The aim is to keep the release process the same, as you say. To take a
>>> specific example, I was looking at the quiesce module, the sort of thing
>>> that the pom.xml would need to indicate is:
>>>
>>> 1) Quiesce module depends on released versions of parent, testsupport,
>>> util
>>> (this is easy)
>>> 2) Quiesce module depends on a released version of the quiesce api (one
>>> of
>>> the agregator's sub-modules) but development versions of the
>>> implementation
>>> sub-modules.
>>>
>>> At the moment to make step 2 work it's necessary to override the default
>>> package imports for, say, the quiesce manager implementation and comment
>>> out quiesce-api in the modules section. After that I get something which
>>> builds and runs - the quiesce manager implementation bundle has the
>>> correct
>>> package imports. I've checked in the quiesce pom (with debug in it). I'm
>>> not
>>> quite sure what the release process will do with this, so I need to
>>> check.
>>>
>>>
>>> Zoe
>>>
>>>
>>>> On Thu, Feb 3, 2011 at 16:11,<zo...@apache.org>    wrote:
>>>>>
>>>>> Author: zoe
>>>>> Date: Thu Feb  3 15:11:33 2011
>>>>> New Revision: 1066827
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1066827&view=rev
>>>>> Log:
>>>>> recreating with 0.4 from trunk
>>>>>
>>>>> Added:
>>>>>    aries/branches/experimental-release-by-module/
>>>>>      - copied from r1066825, aries/trunk/
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Release / verisoning requirements (was Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/)

Posted by Felix Meschberger <fm...@gmail.com>.

Hi,

I think it was Tim who made an important statement: Given Aries would go
for semantic versioning and you go losening it allowing for intermediate
version updates to give way for potential future updates you would
alienate clients holding on to semantic versioning.

Consider:

Aries provides blurb, v 1.0
Client uses blurb, v [1.0,1.1)
Aries releases blurb v 1.1 without changes
Client fails ...

Regards
Felix

Am Dienstag, den 08.02.2011, 13:46 +0100 schrieb Guillaume Nodet: 
> So do you think we should weaken the semantic versioning guidelines in
> order to accomodate being able to do bug fix releases ?
> Or is there a better alternative ?
> 
> I know you haven't implied anything, but if nobody imply nor say
> anything, it doesn't really help solving the problems i've raised.
> 
> On Tue, Feb 8, 2011 at 13:41, Alasdair Nottingham <no...@apache.org> wrote:
> > I have made no such statement, nor have I implied any such thing.
> >
> > Alasdair
> >
> > On 8 February 2011 12:18, Guillaume Nodet <gn...@gmail.com> wrote:
> >> So you don't see any problem in not being *able to* delivery a bug fix
> >> bundle which will only fix a bug in two years ? Because it seems to me
> >> a direct consequence of a strict application of the semantic
> >> verisoning guidelines.
> >>
> >> On Tue, Feb 8, 2011 at 11:52, Alasdair Nottingham <no...@apache.org> wrote:
> >>> The packages in util are all API, which is why they need to be
> >>> exported. Given that PropertyPlaceholder is exported so other people
> >>> can extend it I would argue that also makes it API, although I would
> >>> prefer to be able to hide the implementation details of blueprint.
> >>>
> >>> Alasdair
> >>>
> >>> On 7 February 2011 19:20, Guillaume Nodet <gn...@gmail.com> wrote:
> >>>> In blueprint-cm, we have
> >>>> org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder
> >>>> inheriting org.apache.aries.blueprint.ext.PropertyPlaceholder.  That's
> >>>> the first reason i've seen, there may be others.  Aries-utils is also
> >>>> full of packages with code (well, it's purpose is to share code, so
> >>>> that's kinda expected).
> >>>>
> >>>> On Mon, Feb 7, 2011 at 20:12, Alasdair Nottingham <no...@apache.org> wrote:
> >>>>> If they aren't API then why are we exporting them?
> >>>>>
> >>>>> On 7 February 2011 16:53, Guillaume Nodet <gn...@gmail.com> wrote:
> >>>>>> On Mon, Feb 7, 2011 at 17:26, Timothy Ward <ti...@apache.org> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> >>>> Before we go in any particular direction we must agree, that's true. Is
> >>>>>>>> >>>> it
> >>>>>>>> >>>> possible to agree with these goals now:
> >>>>>>>> >>>>
> >>>>>>>> >>>> 1) As an OSGi project we must demonstrate best practice in our use of
> >>>>>>>> >>>> semantic versioning at bundle and package level
> >>>>>>>> >>>
> >>>>>>>> >>> Agreed, though I don't think there's much semantic implied at the bundle
> >>>>>>>> >>> level.
> >>>>>>>> >>>
> >>>>>>>> >>>> 2) A build and release process which allows us to do
> >>>>>>>> >>>>    (a) A release of everything in one go with associated samples which
> >>>>>>>> >>>> are
> >>>>>>>> >>>> therefore guaranteed to work together
> >>>>>>>> >>>>    (b) Release by module - with the correctly versioned bundles of
> >>>>>>>> >>>> sub-modules
> >>>>>>>> >>>>    (c) To avoid having to do release by sub-module (eg not having to do
> >>>>>>>> >>>> 17
> >>>>>>>> >>>> separate release steps for blueprint)
> >>>>>>>> >>>
> >>>>>>>> >>> Well, those are side issues imho and I think they conflict with the
> >>>>>>>> >>> requirements I propose below.
> >>>>>>>> >>>
> >>>>>>>> >>> I'd rather have the following requirements:
> >>>>>>>> >>>  1. correct osgi semantic versioning
> >>>>>>>> >>>  2. a release must have a buildable source distribution (that's
> >>>>>>>> >>> really an asf requirement, as the source distribution *is* really the
> >>>>>>>> >>> release from an asf pov)
> >>>>>>>> >>>  3. a release should have some release notes listing the changes in
> >>>>>>>> >>> that release
> >>>>>>>> >>>  4. a release must be publicly announced
> >>>>>>>> >>>  5. users should have an easy way to download the bundles needed for
> >>>>>>>> >>> a given component (blueprint, etc...)
> >>>>>>>> >>>  6. easy tagging / branching mechanism
> >>>>>>>> >>>
> >>>>>>>> >> I'd also like to add those requirements:
> >>>>>>>> >>    7. a way to provide bug fix releases
> >>>>>>>> >>    8. a way to ensure that a given component does not have conflicting
> >>>>>>>> >> dependencies
> >>>>>>>> >>
> >>>>>>>> >> #7 is really important in my opinion, even more than #5 and #6.  I
> >>>>>>>> >> can't even imagine how I would tell my customers I can't even do a bug
> >>>>>>>> >> fix release.
> >>>>>>>> >>
> >>>>>>>> >> #8 is about mitigating the dependency hell so that we actaully have
> >>>>>>>> >> the ability to deploy a component which does not require two
> >>>>>>>> >> dependencies with an incompatible version (i.e. for aries blueprint
> >>>>>>>> >> x.y  we don't end up with requiring both aries-utils 1.x and
> >>>>>>>> >> aries-utils 2.x).  This requirement is definitely not a must-have, but
> >>>>>>>> >> a nice to have, as it's really for ease of use and consumption of our
> >>>>>>>> >> components.
> >>>>>>>> >>
> >>>>>>>> >> I haven't heard any feedback so far, but I think starting from what we
> >>>>>>>> >> want is a better idea than investigating a technical solution now.  At
> >>>>>>>> >> least discussing those requirements may end up to doing some
> >>>>>>>> >> compromise over others if they are somewhat incompatible (i..e we
> >>>>>>>> >> don't find a technical solution to solve all those requirements).
> >>>>>>>> >
> >>>>>>>> > I didn't reply earlier because:
> >>>>>>>> >
> >>>>>>>> > (a) I'm not sure what in your requirements conflicts exactly with my
> >>>>>>>> > original suggestions? In any case I'm quite happy to abandon my suggestions
> >>>>>>>> > in favour of yours.
> >>>>>>>> > (b) I'm still trying to understand how we satisfy requirement "1. Correct
> >>>>>>>> > osgi semantic versioning"
> >>>>>>>> >
> >>>>>>>> > Requirement 2, 3, 4 are relatively easy to satisfy.
> >>>>>>>> > Requirements 5, 6, 7 are tied up in the semantic versioning discussion and I
> >>>>>>>> > believe that if we choose to implement semantic versioning there are at
> >>>>>>>> > least some implications for the way in which we meet requirements 5, 6, and
> >>>>>>>> > 7. Not sure about 8.
> >>>>>>>> >
> >>>>>>>> > So, as a list of requirements I don't think there is too much disagreement,
> >>>>>>>> > although perhaps other people would like chip in with their views.
> >>>>>>>> > As I said, the reason for experimenting is about how to satisfy requirement
> >>>>>>>> > 1 with the others. I feel that it's rather poor form that we (as an OSGi
> >>>>>>>> > project) don't meet requirement 1 at the moment :-)
> >>>>>>>> >
> >>>>>>>>
> >>>>>>>> Well, given I still haven't understood how we're going to release
> >>>>>>>> things (per bundle or per component, as it seems a single whole
> >>>>>>>> release hasn't really received much support), I think our current
> >>>>>>>> layout conflict with #6 and we still haven't found a clear way to
> >>>>>>>> align #1 with #7 afaik.
> >>>>>>>
> >>>>>>> #1 and #7 are compatible as long as you don't change your API in an incompatible way (for anyone). This should be a requirement of an "in service" fix anyway so it isn't restrictive. Subsequent releases can export at the same version (assuming it contains the fix) or increment the micro version again if needs be. If you've written your bundles well the fix is very unlikely to affect a package version anyway, requiring only a micro increment to the bundle version. This doesn't seem incompatible with #7 at all.
> >>>>>>
> >>>>>> That's would only work if we have package versions on pure API
> >>>>>> packages only.  We have several bundles that export packages that are
> >>>>>> not real API and which contain code.  We're not talking about an ideal
> >>>>>> world here, but about real code.
> >>>>>>
> >>>>>>>
> >>>>>>> Tim
> >>>>>>>
> >>>>>>>>
> >>>>>>>> > Zoe
> >>>>>>>> >>
> >>>>>>>> >>
> >>>>>>>> >>
> >>>>>>>> >
> >>>>>>>> >
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Cheers,
> >>>>>>>> Guillaume Nodet
> >>>>>>>> ------------------------
> >>>>>>>> Blog: http://gnodet.blogspot.com/
> >>>>>>>> ------------------------
> >>>>>>>> Open Source SOA
> >>>>>>>> http://fusesource.com
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Cheers,
> >>>>>> Guillaume Nodet
> >>>>>> ------------------------
> >>>>>> Blog: http://gnodet.blogspot.com/
> >>>>>> ------------------------
> >>>>>> Open Source SOA
> >>>>>> http://fusesource.com
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Alasdair Nottingham
> >>>>> not@apache.org
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>> Guillaume Nodet
> >>>> ------------------------
> >>>> Blog: http://gnodet.blogspot.com/
> >>>> ------------------------
> >>>> Open Source SOA
> >>>> http://fusesource.com
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Alasdair Nottingham
> >>> not@apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
> 
> 
>