release process questions around versions

[Joe Bohn <jo...@gmail.com>]

We're in the process of releasing our second set of modules.  This sheds 
new light on the module version and release process discussions we had 
earlier.  It also raises some questions about how we ideally want to 
handle certain scenarios now that we are forced to deal with more than 
one release.

1) Should the first release of a new module use the prevailing version 
at the time or do we intend to always start with the logical "1" of a 
first release?  For quiesce we used the prevailing version - 
0.2-incubating.

2) How will we make multiple component versions available in the future 
for download?  If we always release all modules (as we did in our 0.1 
and 0.2 releases) then it's simple - we can create a download page for 
each release and we can create documentation per release.  However, if 
we start to release the modules individually things get a bit more 
complicated.  One possibility is to move from one common download page 
to a download page per module.

3) Are there other benefits in keeping the module versions consistent 
and concurrently releasing all modules rather than individual modules 
that we haven't really considered?  I'm thinking about things like 
documentation, test validation, and samples.

Thinking more about #3 - It seems it might be very difficult to maintain 
our documentation and samples once the module versions begin to diverge. 
  Changes to one module might force us to want to release or update some 
other module, ... such as the case with (and perhaps only with) samples. 
  In fact, samples might be impacted by the release of each module if we 
want to try to keep them as current as possible.  This might result in a 
proliferation of sample releases.  Moreover, the combination of 
modules/versions we use in our sample releases might not demonstrate or 
validate a common set of modules/versions that a user might choose. 
Yes, all valid versions based upon dependencies *should* work fine 
together ... but that assumes nobody makes mistakes.  There is a certain 
comfort (from a user perspective) in knowing that a particular set of 
modules has been tested together in some fashion which can at least be 
partially demonstrated in our samples.

I understand why we started down the path of individual components and I 
definitely agree that it has value ... I'm just rethinking the decision 
now that we are doing our second release and have to deal with multiple 
versions for the first time.  The second release begins to set the 
precedent for how we deal with some of these things.  The fact that we 
basically released everything again with a consistent version makes me 
wonder if that should be our standard process instead of individual 
component versions.

-- 
Joe

Re: release process questions around versions

[Justin Edelson <ju...@gmail.com>]

On 8/23/10 1:35 PM, David Jencks wrote:
> My understanding of our current situation is that we have set up the "subprojects" to support and encourage releasing them on separate schedules but that both the 0.1-incubating and 0.2-incubating releases have happened to support external users rather than because a particular module is in a particularly stable state.  I expect that once at least one module is in a stable state it will proceed on an independent release schedule.
I was under the impression that the JMX spec implementation was stable.
Is this not the case?

Justin

> 
> The main change felix recommends from the procedure in my mind I think we're following :-) is to use the minimal working version of dependencies rather than the latest.  I actually think with appropriate bnd version templates it shouldn't make any difference to what ends up in the import-package header but I don't think the correct bits of bnd are available in the maven-bundle-plugin yet.
> 
> thanks
> david jencks
> 
> 
> On Aug 23, 2010, at 9:19 AM, Felix Meschberger wrote:
> 
>> Hi,
>>
>> On 23.08.2010 17:51, Timothy Ward wrote:
>>>
>>> Hi all,
>>>
>>> I also agree that we need a process by which modules can be released independently from one another. I do, however, think that this should not occur until we are ready to declare a set of modules as a 1.0 release. There are several common utilities and inter-module dependencies that will be very difficult to formalize until release 1.0, particularly because at the moment we do not strictly apply versioning rules to our packages.
>>
>> Don't wait too long. Target the ultimate goal and work towards it. You
>> will, as my experience from Sling tells, refactor package and reorganize
>> bundles.
>>
>> No problems, do it, but keep the goal in mind.
>>
>> Regards
>> Felix
>>
>>>
>>> Regards,
>>>
>>> Tim
>>>
>>> ----------------------------------------
>>>> Date: Mon, 23 Aug 2010 11:08:15 -0400
>>>> From: joebohn@gmail.com
>>>> To: aries-dev@incubator.apache.org
>>>> Subject: Re: release process questions around versions
>>>>
>>>>
>>>> Thanks Zoe and Felix.
>>>>
>>>> I too agree that Felix raises a number of very good points and I also
>>>> believe that we should be striving to release individual modules - it's
>>>> only right and consistent to do so. It's just that our process doesn't
>>>> currently support this well and things like samples get a little messy.
>>>> Thank you too Felix for the pointers to the Sling links - we need to
>>>> look into this more carefully to learn from your experience.
>>>>
>>>> So, I think we have two slightly conflicting goals that we are trying to
>>>> achieve.
>>>>
>>>> 1) We'd like to release individual modules on individual schedules as
>>>> necessary. We need to update our process to accommodate this goal.
>>>>
>>>> 2) While independent, our modules can also work together in concert to
>>>> enable enterprise OSGi applications. As such we would like to
>>>> demonstrate them working together and make it easy for a user to do the
>>>> same.
>>>>
>>>> My original note was primarily to highlight the problem and start a
>>>> discussion. I also did a little "thinking out loud" and perhaps lapsed
>>>> into a bit of monolithic thinking near the end - longing for a more
>>>> simple solution. That probably isn't the best approach. We should be
>>>> able to do something to accomplish both goals - perhaps following
>>>> Sling's lead.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>>> On 8/23/10 10:11 AM, zoe slattery wrote:
>>>>> Felix - thanks. You make some good points. Our current problem is that
>>>>> our development and release process isn't (unlike Felix) a mature
>>>>> process and currently is not designed to facilitate releasing by module.
>>>>>
>>>>> If we go this way we need we need to work through some changes and
>>>>> everyone who contributes need to understand them :-)
>>>>>
>>>>> Thanks again, Zoë
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Sorry to bother from the outside: But, isn't this a project build OSGi
>>>>>> bundles ?
>>>>>>
>>>>>> So I suggest you stop thinking in traditional, monolithic application
>>>>>> terms, where everything always is built and glued together at the same
>>>>>> time.
>>>>>>
>>>>>> In the OSGi world this is fundamentally different: Parts of the
>>>>>> application are built at build-time and glued together at deployment
>>>>>> time.
>>>>>>
>>>>>> This is a big plus to your users in that they don't have to always
>>>>>> update the complete application just in case of a small fix.
>>>>>>
>>>>>> It is adding more to the developer's task, but rightly so: You, the
>>>>>> developer, are fully in charge to ensure compatibility of your module.
>>>>>> This is what "API" is all about.
>>>>>>
>>>>>> Try it, and you will start to enjoy it; really !
>>>>>>
>>>>>> On 22.08.2010 11:03, zoe slattery wrote:
>>>>>>> I agree that this needs some rethinking in the light of experience.
>>>>>>>> We're in the process of releasing our second set of modules. This
>>>>>>>> sheds new light on the module version and release process discussions
>>>>>>>> we had earlier. It also raises some questions about how we ideally
>>>>>>>> want to handle certain scenarios now that we are forced to deal with
>>>>>>>> more than one release.
>>>>>>>>
>>>>>>>> 1) Should the first release of a new module use the prevailing version
>>>>>>>> at the time or do we intend to always start with the logical "1" of a
>>>>>>>> first release? For quiesce we used the prevailing version -
>>>>>>>> 0.2-incubating.
>>>>>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>>>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>>>>>> there needs to be some guidance for developers because I don't think
>>>>>>> it's obvious.
>>>>>>>
>>>>>>> At the same time as introducing quiesce, changes were made to jpa -
>>>>>>> which now depends on quiesce. So, if we were releasing jpa at
>>>>>>> 0.2-incubating it would need to depend on a release of quiesce created
>>>>>>> at the same time and called 0.1-incubating.
>>>>>> Version numbers of modules identify the development history of a single
>>>>>> module. Lets keep it that simple. Don't overlay this semantic with the
>>>>>> semantic of the version of the complete application. This ain't gonna
>>>>>> work in the not so far future. See
>>>>>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>>>>>
>>>>>>>> 2) How will we make multiple component versions available in the
>>>>>>>> future for download? If we always release all modules (as we did in
>>>>>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>>>>>> page for each release and we can create documentation per release.
>>>>>>>> However, if we start to release the modules individually things get a
>>>>>>>> bit more complicated. One possibility is to move from one common
>>>>>>>> download page to a download page per module.
>>>>>>> That would be OK if they were truly independent. I've drawn here the
>>>>>>> dependencies that I observed when I was testing the 0.2-snapshot
>>>>>>> release.
>>>>>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>>>>>> The relationships indicated in the picture just show what happened when
>>>>>>> I tried to build something - so for example, the jpa build failed with
>>>>>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>>>>>> testsupport and parent.
>>>>>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>>>>>> version will depend on some API currently provided by some version of
>>>>>> the quiesce module. The JPA does not care, who actually provides the
>>>>>> API, as long as its there.
>>>>>>
>>>>>> Thus built-time and deployment-time dependencies are not the same in the
>>>>>> OSGi world.
>>>>>>
>>>>>>>> 3) Are there other benefits in keeping the module versions consistent
>>>>>>>> and concurrently releasing all modules rather than individual modules
>>>>>>>> that we haven't really considered? I'm thinking about things like
>>>>>>>> documentation, test validation, and samples.
>>>>>>> The main point of the blog sample is to bring together a number of the
>>>>>>> modules and show them working in one application, I think this might be
>>>>>>> true of ariestrader too. Trying to think about how to maintain either of
>>>>>>> these samples to work with a set of independently released modules is
>>>>>>> making my head hurt.
>>>>>>>> Thinking more about #3 - It seems it might be very difficult to
>>>>>>>> maintain our documentation and samples once the module versions begin
>>>>>>>> to diverge. Changes to one module might force us to want to release
>>>>>>>> or update some other module, ... such as the case with (and perhaps
>>>>>>>> only with) samples. In fact, samples might be impacted by the release
>>>>>>>> of each module if we want to try to keep them as current as possible.
>>>>>>>> This might result in a proliferation of sample releases. Moreover,
>>>>>>>> the combination of modules/versions we use in our sample releases
>>>>>>>> might not demonstrate or validate a common set of modules/versions
>>>>>>>> that a user might choose. Yes, all valid versions based upon
>>>>>>>> dependencies *should* work fine together ... but that assumes nobody
>>>>>>>> makes mistakes. There is a certain comfort (from a user perspective)
>>>>>>>> in knowing that a particular set of modules has been tested together
>>>>>>>> in some fashion which can at least be partially demonstrated in our
>>>>>>>> samples.
>>>>>>> I agree.
>>>>>>>> I understand why we started down the path of individual components and
>>>>>>>> I definitely agree that it has value ... I'm just rethinking the
>>>>>>>> decision now that we are doing our second release and have to deal
>>>>>>>> with multiple versions for the first time. The second release begins
>>>>>>>> to set the precedent for how we deal with some of these things. The
>>>>>>>> fact that we basically released everything again with a consistent
>>>>>>>> version makes me wonder if that should be our standard process instead
>>>>>>>> of individual component versions.
>>>>>>> There are advantages in being able to release a module separately. For
>>>>>>> example if we find something we need to fix in one module, and it's a
>>>>>>> self contained fix, we could create a new release of that module quite
>>>>>>> quickly. On the other hand, the slow part of the release process (72
>>>>>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>>>>>> same.
>>>>>> Yeah, sure that may seem a problem (but there is a reason for this,
>>>>>> though). But this should influence the decision of whether to do
>>>>>> single-module releases or not.
>>>>>>
>>>>>>> On balance I'm in favour of a single release at a set level - however -
>>>>>>> if we can find an absolutely crystal clear way to document a
>>>>>>> release-by-module system I think it could work; I'm worried by the
>>>>>>> complexity it would lead to in documentation and samples.
>>>>>> I fear you worry on the wrong end of the story. Worry about the
>>>>>> interfaces between your modules and look at what the modules really
>>>>>> need. Your modules depend on services and API; they don't depend on
>>>>>> other modules.
>>>>>>
>>>>>> At one point in time you will realize that you have some modules which
>>>>>> are mostly stable and some modules which are under heavy development. So
>>>>>> you will release the moving parts (modules under development) and not
>>>>>> release the static parts.
>>>>>>
>>>>>> Doing module releases also enables you to "release early, release often".
>>>>>>
>>>>>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>>>>>> about.
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>> Zoë
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>> 		 	   		  
>>
> 

Re: release process questions around versions

[David Jencks <da...@yahoo.com>]

My understanding of our current situation is that we have set up the "subprojects" to support and encourage releasing them on separate schedules but that both the 0.1-incubating and 0.2-incubating releases have happened to support external users rather than because a particular module is in a particularly stable state.  I expect that once at least one module is in a stable state it will proceed on an independent release schedule.

The main change felix recommends from the procedure in my mind I think we're following :-) is to use the minimal working version of dependencies rather than the latest.  I actually think with appropriate bnd version templates it shouldn't make any difference to what ends up in the import-package header but I don't think the correct bits of bnd are available in the maven-bundle-plugin yet.

thanks
david jencks


On Aug 23, 2010, at 9:19 AM, Felix Meschberger wrote:

> Hi,
> 
> On 23.08.2010 17:51, Timothy Ward wrote:
>> 
>> Hi all,
>> 
>> I also agree that we need a process by which modules can be released independently from one another. I do, however, think that this should not occur until we are ready to declare a set of modules as a 1.0 release. There are several common utilities and inter-module dependencies that will be very difficult to formalize until release 1.0, particularly because at the moment we do not strictly apply versioning rules to our packages.
> 
> Don't wait too long. Target the ultimate goal and work towards it. You
> will, as my experience from Sling tells, refactor package and reorganize
> bundles.
> 
> No problems, do it, but keep the goal in mind.
> 
> Regards
> Felix
> 
>> 
>> Regards,
>> 
>> Tim
>> 
>> ----------------------------------------
>>> Date: Mon, 23 Aug 2010 11:08:15 -0400
>>> From: joebohn@gmail.com
>>> To: aries-dev@incubator.apache.org
>>> Subject: Re: release process questions around versions
>>> 
>>> 
>>> Thanks Zoe and Felix.
>>> 
>>> I too agree that Felix raises a number of very good points and I also
>>> believe that we should be striving to release individual modules - it's
>>> only right and consistent to do so. It's just that our process doesn't
>>> currently support this well and things like samples get a little messy.
>>> Thank you too Felix for the pointers to the Sling links - we need to
>>> look into this more carefully to learn from your experience.
>>> 
>>> So, I think we have two slightly conflicting goals that we are trying to
>>> achieve.
>>> 
>>> 1) We'd like to release individual modules on individual schedules as
>>> necessary. We need to update our process to accommodate this goal.
>>> 
>>> 2) While independent, our modules can also work together in concert to
>>> enable enterprise OSGi applications. As such we would like to
>>> demonstrate them working together and make it easy for a user to do the
>>> same.
>>> 
>>> My original note was primarily to highlight the problem and start a
>>> discussion. I also did a little "thinking out loud" and perhaps lapsed
>>> into a bit of monolithic thinking near the end - longing for a more
>>> simple solution. That probably isn't the best approach. We should be
>>> able to do something to accomplish both goals - perhaps following
>>> Sling's lead.
>>> 
>>> Thanks,
>>> Joe
>>> 
>>> 
>>> On 8/23/10 10:11 AM, zoe slattery wrote:
>>>> Felix - thanks. You make some good points. Our current problem is that
>>>> our development and release process isn't (unlike Felix) a mature
>>>> process and currently is not designed to facilitate releasing by module.
>>>> 
>>>> If we go this way we need we need to work through some changes and
>>>> everyone who contributes need to understand them :-)
>>>> 
>>>> Thanks again, Zoë
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Sorry to bother from the outside: But, isn't this a project build OSGi
>>>>> bundles ?
>>>>> 
>>>>> So I suggest you stop thinking in traditional, monolithic application
>>>>> terms, where everything always is built and glued together at the same
>>>>> time.
>>>>> 
>>>>> In the OSGi world this is fundamentally different: Parts of the
>>>>> application are built at build-time and glued together at deployment
>>>>> time.
>>>>> 
>>>>> This is a big plus to your users in that they don't have to always
>>>>> update the complete application just in case of a small fix.
>>>>> 
>>>>> It is adding more to the developer's task, but rightly so: You, the
>>>>> developer, are fully in charge to ensure compatibility of your module.
>>>>> This is what "API" is all about.
>>>>> 
>>>>> Try it, and you will start to enjoy it; really !
>>>>> 
>>>>> On 22.08.2010 11:03, zoe slattery wrote:
>>>>>> I agree that this needs some rethinking in the light of experience.
>>>>>>> We're in the process of releasing our second set of modules. This
>>>>>>> sheds new light on the module version and release process discussions
>>>>>>> we had earlier. It also raises some questions about how we ideally
>>>>>>> want to handle certain scenarios now that we are forced to deal with
>>>>>>> more than one release.
>>>>>>> 
>>>>>>> 1) Should the first release of a new module use the prevailing version
>>>>>>> at the time or do we intend to always start with the logical "1" of a
>>>>>>> first release? For quiesce we used the prevailing version -
>>>>>>> 0.2-incubating.
>>>>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>>>>> there needs to be some guidance for developers because I don't think
>>>>>> it's obvious.
>>>>>> 
>>>>>> At the same time as introducing quiesce, changes were made to jpa -
>>>>>> which now depends on quiesce. So, if we were releasing jpa at
>>>>>> 0.2-incubating it would need to depend on a release of quiesce created
>>>>>> at the same time and called 0.1-incubating.
>>>>> Version numbers of modules identify the development history of a single
>>>>> module. Lets keep it that simple. Don't overlay this semantic with the
>>>>> semantic of the version of the complete application. This ain't gonna
>>>>> work in the not so far future. See
>>>>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>>>> 
>>>>>>> 2) How will we make multiple component versions available in the
>>>>>>> future for download? If we always release all modules (as we did in
>>>>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>>>>> page for each release and we can create documentation per release.
>>>>>>> However, if we start to release the modules individually things get a
>>>>>>> bit more complicated. One possibility is to move from one common
>>>>>>> download page to a download page per module.
>>>>>> That would be OK if they were truly independent. I've drawn here the
>>>>>> dependencies that I observed when I was testing the 0.2-snapshot
>>>>>> release.
>>>>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>>>>> The relationships indicated in the picture just show what happened when
>>>>>> I tried to build something - so for example, the jpa build failed with
>>>>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>>>>> testsupport and parent.
>>>>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>>>>> version will depend on some API currently provided by some version of
>>>>> the quiesce module. The JPA does not care, who actually provides the
>>>>> API, as long as its there.
>>>>> 
>>>>> Thus built-time and deployment-time dependencies are not the same in the
>>>>> OSGi world.
>>>>> 
>>>>>>> 3) Are there other benefits in keeping the module versions consistent
>>>>>>> and concurrently releasing all modules rather than individual modules
>>>>>>> that we haven't really considered? I'm thinking about things like
>>>>>>> documentation, test validation, and samples.
>>>>>> The main point of the blog sample is to bring together a number of the
>>>>>> modules and show them working in one application, I think this might be
>>>>>> true of ariestrader too. Trying to think about how to maintain either of
>>>>>> these samples to work with a set of independently released modules is
>>>>>> making my head hurt.
>>>>>>> Thinking more about #3 - It seems it might be very difficult to
>>>>>>> maintain our documentation and samples once the module versions begin
>>>>>>> to diverge. Changes to one module might force us to want to release
>>>>>>> or update some other module, ... such as the case with (and perhaps
>>>>>>> only with) samples. In fact, samples might be impacted by the release
>>>>>>> of each module if we want to try to keep them as current as possible.
>>>>>>> This might result in a proliferation of sample releases. Moreover,
>>>>>>> the combination of modules/versions we use in our sample releases
>>>>>>> might not demonstrate or validate a common set of modules/versions
>>>>>>> that a user might choose. Yes, all valid versions based upon
>>>>>>> dependencies *should* work fine together ... but that assumes nobody
>>>>>>> makes mistakes. There is a certain comfort (from a user perspective)
>>>>>>> in knowing that a particular set of modules has been tested together
>>>>>>> in some fashion which can at least be partially demonstrated in our
>>>>>>> samples.
>>>>>> I agree.
>>>>>>> I understand why we started down the path of individual components and
>>>>>>> I definitely agree that it has value ... I'm just rethinking the
>>>>>>> decision now that we are doing our second release and have to deal
>>>>>>> with multiple versions for the first time. The second release begins
>>>>>>> to set the precedent for how we deal with some of these things. The
>>>>>>> fact that we basically released everything again with a consistent
>>>>>>> version makes me wonder if that should be our standard process instead
>>>>>>> of individual component versions.
>>>>>> There are advantages in being able to release a module separately. For
>>>>>> example if we find something we need to fix in one module, and it's a
>>>>>> self contained fix, we could create a new release of that module quite
>>>>>> quickly. On the other hand, the slow part of the release process (72
>>>>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>>>>> same.
>>>>> Yeah, sure that may seem a problem (but there is a reason for this,
>>>>> though). But this should influence the decision of whether to do
>>>>> single-module releases or not.
>>>>> 
>>>>>> On balance I'm in favour of a single release at a set level - however -
>>>>>> if we can find an absolutely crystal clear way to document a
>>>>>> release-by-module system I think it could work; I'm worried by the
>>>>>> complexity it would lead to in documentation and samples.
>>>>> I fear you worry on the wrong end of the story. Worry about the
>>>>> interfaces between your modules and look at what the modules really
>>>>> need. Your modules depend on services and API; they don't depend on
>>>>> other modules.
>>>>> 
>>>>> At one point in time you will realize that you have some modules which
>>>>> are mostly stable and some modules which are under heavy development. So
>>>>> you will release the moving parts (modules under development) and not
>>>>> release the static parts.
>>>>> 
>>>>> Doing module releases also enables you to "release early, release often".
>>>>> 
>>>>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>>>>> about.
>>>>> 
>>>>> Regards
>>>>> Felix
>>>>> 
>>>>>> Zoë
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Joe
>> 		 	   		  
> 

Re: release process questions around versions

[Felix Meschberger <fm...@gmail.com>]

Hi,

On 23.08.2010 17:51, Timothy Ward wrote:
> 
> Hi all,
> 
> I also agree that we need a process by which modules can be released independently from one another. I do, however, think that this should not occur until we are ready to declare a set of modules as a 1.0 release. There are several common utilities and inter-module dependencies that will be very difficult to formalize until release 1.0, particularly because at the moment we do not strictly apply versioning rules to our packages.

Don't wait too long. Target the ultimate goal and work towards it. You
will, as my experience from Sling tells, refactor package and reorganize
bundles.

No problems, do it, but keep the goal in mind.

Regards
Felix

> 
> Regards,
> 
> Tim
> 
> ----------------------------------------
>> Date: Mon, 23 Aug 2010 11:08:15 -0400
>> From: joebohn@gmail.com
>> To: aries-dev@incubator.apache.org
>> Subject: Re: release process questions around versions
>>
>>
>> Thanks Zoe and Felix.
>>
>> I too agree that Felix raises a number of very good points and I also
>> believe that we should be striving to release individual modules - it's
>> only right and consistent to do so. It's just that our process doesn't
>> currently support this well and things like samples get a little messy.
>> Thank you too Felix for the pointers to the Sling links - we need to
>> look into this more carefully to learn from your experience.
>>
>> So, I think we have two slightly conflicting goals that we are trying to
>> achieve.
>>
>> 1) We'd like to release individual modules on individual schedules as
>> necessary. We need to update our process to accommodate this goal.
>>
>> 2) While independent, our modules can also work together in concert to
>> enable enterprise OSGi applications. As such we would like to
>> demonstrate them working together and make it easy for a user to do the
>> same.
>>
>> My original note was primarily to highlight the problem and start a
>> discussion. I also did a little "thinking out loud" and perhaps lapsed
>> into a bit of monolithic thinking near the end - longing for a more
>> simple solution. That probably isn't the best approach. We should be
>> able to do something to accomplish both goals - perhaps following
>> Sling's lead.
>>
>> Thanks,
>> Joe
>>
>>
>> On 8/23/10 10:11 AM, zoe slattery wrote:
>>> Felix - thanks. You make some good points. Our current problem is that
>>> our development and release process isn't (unlike Felix) a mature
>>> process and currently is not designed to facilitate releasing by module.
>>>
>>> If we go this way we need we need to work through some changes and
>>> everyone who contributes need to understand them :-)
>>>
>>> Thanks again, Zoë
>>>
>>>> Hi,
>>>>
>>>> Sorry to bother from the outside: But, isn't this a project build OSGi
>>>> bundles ?
>>>>
>>>> So I suggest you stop thinking in traditional, monolithic application
>>>> terms, where everything always is built and glued together at the same
>>>> time.
>>>>
>>>> In the OSGi world this is fundamentally different: Parts of the
>>>> application are built at build-time and glued together at deployment
>>>> time.
>>>>
>>>> This is a big plus to your users in that they don't have to always
>>>> update the complete application just in case of a small fix.
>>>>
>>>> It is adding more to the developer's task, but rightly so: You, the
>>>> developer, are fully in charge to ensure compatibility of your module.
>>>> This is what "API" is all about.
>>>>
>>>> Try it, and you will start to enjoy it; really !
>>>>
>>>> On 22.08.2010 11:03, zoe slattery wrote:
>>>>> I agree that this needs some rethinking in the light of experience.
>>>>>> We're in the process of releasing our second set of modules. This
>>>>>> sheds new light on the module version and release process discussions
>>>>>> we had earlier. It also raises some questions about how we ideally
>>>>>> want to handle certain scenarios now that we are forced to deal with
>>>>>> more than one release.
>>>>>>
>>>>>> 1) Should the first release of a new module use the prevailing version
>>>>>> at the time or do we intend to always start with the logical "1" of a
>>>>>> first release? For quiesce we used the prevailing version -
>>>>>> 0.2-incubating.
>>>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>>>> there needs to be some guidance for developers because I don't think
>>>>> it's obvious.
>>>>>
>>>>> At the same time as introducing quiesce, changes were made to jpa -
>>>>> which now depends on quiesce. So, if we were releasing jpa at
>>>>> 0.2-incubating it would need to depend on a release of quiesce created
>>>>> at the same time and called 0.1-incubating.
>>>> Version numbers of modules identify the development history of a single
>>>> module. Lets keep it that simple. Don't overlay this semantic with the
>>>> semantic of the version of the complete application. This ain't gonna
>>>> work in the not so far future. See
>>>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>>>
>>>>>> 2) How will we make multiple component versions available in the
>>>>>> future for download? If we always release all modules (as we did in
>>>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>>>> page for each release and we can create documentation per release.
>>>>>> However, if we start to release the modules individually things get a
>>>>>> bit more complicated. One possibility is to move from one common
>>>>>> download page to a download page per module.
>>>>> That would be OK if they were truly independent. I've drawn here the
>>>>> dependencies that I observed when I was testing the 0.2-snapshot
>>>>> release.
>>>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>>>> The relationships indicated in the picture just show what happened when
>>>>> I tried to build something - so for example, the jpa build failed with
>>>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>>>> testsupport and parent.
>>>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>>>> version will depend on some API currently provided by some version of
>>>> the quiesce module. The JPA does not care, who actually provides the
>>>> API, as long as its there.
>>>>
>>>> Thus built-time and deployment-time dependencies are not the same in the
>>>> OSGi world.
>>>>
>>>>>> 3) Are there other benefits in keeping the module versions consistent
>>>>>> and concurrently releasing all modules rather than individual modules
>>>>>> that we haven't really considered? I'm thinking about things like
>>>>>> documentation, test validation, and samples.
>>>>> The main point of the blog sample is to bring together a number of the
>>>>> modules and show them working in one application, I think this might be
>>>>> true of ariestrader too. Trying to think about how to maintain either of
>>>>> these samples to work with a set of independently released modules is
>>>>> making my head hurt.
>>>>>> Thinking more about #3 - It seems it might be very difficult to
>>>>>> maintain our documentation and samples once the module versions begin
>>>>>> to diverge. Changes to one module might force us to want to release
>>>>>> or update some other module, ... such as the case with (and perhaps
>>>>>> only with) samples. In fact, samples might be impacted by the release
>>>>>> of each module if we want to try to keep them as current as possible.
>>>>>> This might result in a proliferation of sample releases. Moreover,
>>>>>> the combination of modules/versions we use in our sample releases
>>>>>> might not demonstrate or validate a common set of modules/versions
>>>>>> that a user might choose. Yes, all valid versions based upon
>>>>>> dependencies *should* work fine together ... but that assumes nobody
>>>>>> makes mistakes. There is a certain comfort (from a user perspective)
>>>>>> in knowing that a particular set of modules has been tested together
>>>>>> in some fashion which can at least be partially demonstrated in our
>>>>>> samples.
>>>>> I agree.
>>>>>> I understand why we started down the path of individual components and
>>>>>> I definitely agree that it has value ... I'm just rethinking the
>>>>>> decision now that we are doing our second release and have to deal
>>>>>> with multiple versions for the first time. The second release begins
>>>>>> to set the precedent for how we deal with some of these things. The
>>>>>> fact that we basically released everything again with a consistent
>>>>>> version makes me wonder if that should be our standard process instead
>>>>>> of individual component versions.
>>>>> There are advantages in being able to release a module separately. For
>>>>> example if we find something we need to fix in one module, and it's a
>>>>> self contained fix, we could create a new release of that module quite
>>>>> quickly. On the other hand, the slow part of the release process (72
>>>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>>>> same.
>>>> Yeah, sure that may seem a problem (but there is a reason for this,
>>>> though). But this should influence the decision of whether to do
>>>> single-module releases or not.
>>>>
>>>>> On balance I'm in favour of a single release at a set level - however -
>>>>> if we can find an absolutely crystal clear way to document a
>>>>> release-by-module system I think it could work; I'm worried by the
>>>>> complexity it would lead to in documentation and samples.
>>>> I fear you worry on the wrong end of the story. Worry about the
>>>> interfaces between your modules and look at what the modules really
>>>> need. Your modules depend on services and API; they don't depend on
>>>> other modules.
>>>>
>>>> At one point in time you will realize that you have some modules which
>>>> are mostly stable and some modules which are under heavy development. So
>>>> you will release the moving parts (modules under development) and not
>>>> release the static parts.
>>>>
>>>> Doing module releases also enables you to "release early, release often".
>>>>
>>>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>>>> about.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> Zoë
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Joe
>  		 	   		  

Re: release process questions around versions

[David Jencks <da...@yahoo.com>]

On Aug 24, 2010, at 6:00 AM, zoe slattery wrote:

> On 23/08/2010 16:51, Timothy Ward wrote:
>> Hi all,
>> 
>> I also agree that we need a process by which modules can be released independently from one another. I do, however, think that this should not occur until we are ready to declare a set of modules as a 1.0 release. There are several common utilities and inter-module dependencies that will be very difficult to formalize until release 1.0, particularly because at the moment we do not strictly apply versioning rules to our packages.
> Yes - I think that's the short summary of where we are.
> 
> I spent some time thinking about what would have to change in our development process when we release by module. There are problems that I don't know how to solve, but maybe someone else does. Here is one of them:
> 
> It is really important that people can build our released source code without having to modify the poms. Consider this example - at the moment the candidate release pom.xml in the JPA has dependencies which look like this:
> 
> <dependency>
> <groupId>org.apache.aries</groupId>
> <artifactId>org.apache.aries.util</artifactId>
> <version>0.2-incubating</version>
> </dependency>
> 
> So, we would need to have released a 0.2-incubating level of org.apache.aries.util before (or at the same time as) the 0.2 incubating level of blueprint.
> 
> I think this means that we need to change all the projects in trunk to depend on released versions of other projects. So a 0.3-incubating-SNAPSHOT version of JPA in trunk would have this in it's pom.xml
> 
> <dependency>
> <groupId>org.apache.aries</groupId>
> <artifactId>org.apache.aries.util</artifactId>
> <version>0.2-incubating</version>
> </dependency>
> 
> This means that we will not be testing the development versions of other projects - which is fine as long as they don't change.
> 
> What would happen in this scenario when a util developer introduced an API breaking change in trunk? Surely the development (trunk) version of JPA should be modified to depend on the new version of util which is under development? How would the JPA maintainer know this had to happen? Is there any tooling to automate it?

Let's pretend for a moment that we are using osgi package versions correctly and that they are derived from maven  versions.

An API breaking change means going from say 2.3.4 to 3.0.  That's a big deal.  Other subprojects may or may not want to make use of this incompatible upgrade.  An osgi environment should be able to run both util versions at the same time without problems.  

I think a more realistic use case is a bug fix without api change from e.g either 2.3.4 to 2.3.5 or 2.4.0.  This will presumably be motivated by a problem in some "using" project so that project will right away start using the new snapshot dependency.  Since there are no api incompatibilities other projects don't need to upgrade and the import package version ranges should allow using the new version if present.

In either case you can use various versions-maven-plugin commands to  find out about and update versions for dependencies.

So I don't really see any problems with each subproject having independent versions.

thanks
david jencks




> 
> I think we need answers to these, and some similar more involved questions about samples and docs, before we can switch to a module based release.
> 
> Zoe
> 
>> Regards,
>> 
>> Tim
>> 
>> ----------------------------------------
>>> Date: Mon, 23 Aug 2010 11:08:15 -0400
>>> From: joebohn@gmail.com
>>> To: aries-dev@incubator.apache.org
>>> Subject: Re: release process questions around versions
>>> 
>>> 
>>> Thanks Zoe and Felix.
>>> 
>>> I too agree that Felix raises a number of very good points and I also
>>> believe that we should be striving to release individual modules - it's
>>> only right and consistent to do so. It's just that our process doesn't
>>> currently support this well and things like samples get a little messy.
>>> Thank you too Felix for the pointers to the Sling links - we need to
>>> look into this more carefully to learn from your experience.
>>> 
>>> So, I think we have two slightly conflicting goals that we are trying to
>>> achieve.
>>> 
>>> 1) We'd like to release individual modules on individual schedules as
>>> necessary. We need to update our process to accommodate this goal.
>>> 
>>> 2) While independent, our modules can also work together in concert to
>>> enable enterprise OSGi applications. As such we would like to
>>> demonstrate them working together and make it easy for a user to do the
>>> same.
>>> 
>>> My original note was primarily to highlight the problem and start a
>>> discussion. I also did a little "thinking out loud" and perhaps lapsed
>>> into a bit of monolithic thinking near the end - longing for a more
>>> simple solution. That probably isn't the best approach. We should be
>>> able to do something to accomplish both goals - perhaps following
>>> Sling's lead.
>>> 
>>> Thanks,
>>> Joe
>>> 
>>> 
>>> On 8/23/10 10:11 AM, zoe slattery wrote:
>>>> Felix - thanks. You make some good points. Our current problem is that
>>>> our development and release process isn't (unlike Felix) a mature
>>>> process and currently is not designed to facilitate releasing by module.
>>>> 
>>>> If we go this way we need we need to work through some changes and
>>>> everyone who contributes need to understand them :-)
>>>> 
>>>> Thanks again, Zoë
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Sorry to bother from the outside: But, isn't this a project build OSGi
>>>>> bundles ?
>>>>> 
>>>>> So I suggest you stop thinking in traditional, monolithic application
>>>>> terms, where everything always is built and glued together at the same
>>>>> time.
>>>>> 
>>>>> In the OSGi world this is fundamentally different: Parts of the
>>>>> application are built at build-time and glued together at deployment
>>>>> time.
>>>>> 
>>>>> This is a big plus to your users in that they don't have to always
>>>>> update the complete application just in case of a small fix.
>>>>> 
>>>>> It is adding more to the developer's task, but rightly so: You, the
>>>>> developer, are fully in charge to ensure compatibility of your module.
>>>>> This is what "API" is all about.
>>>>> 
>>>>> Try it, and you will start to enjoy it; really !
>>>>> 
>>>>> On 22.08.2010 11:03, zoe slattery wrote:
>>>>>> I agree that this needs some rethinking in the light of experience.
>>>>>>> We're in the process of releasing our second set of modules. This
>>>>>>> sheds new light on the module version and release process discussions
>>>>>>> we had earlier. It also raises some questions about how we ideally
>>>>>>> want to handle certain scenarios now that we are forced to deal with
>>>>>>> more than one release.
>>>>>>> 
>>>>>>> 1) Should the first release of a new module use the prevailing version
>>>>>>> at the time or do we intend to always start with the logical "1" of a
>>>>>>> first release? For quiesce we used the prevailing version -
>>>>>>> 0.2-incubating.
>>>>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>>>>> there needs to be some guidance for developers because I don't think
>>>>>> it's obvious.
>>>>>> 
>>>>>> At the same time as introducing quiesce, changes were made to jpa -
>>>>>> which now depends on quiesce. So, if we were releasing jpa at
>>>>>> 0.2-incubating it would need to depend on a release of quiesce created
>>>>>> at the same time and called 0.1-incubating.
>>>>> Version numbers of modules identify the development history of a single
>>>>> module. Lets keep it that simple. Don't overlay this semantic with the
>>>>> semantic of the version of the complete application. This ain't gonna
>>>>> work in the not so far future. See
>>>>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>>>> 
>>>>>>> 2) How will we make multiple component versions available in the
>>>>>>> future for download? If we always release all modules (as we did in
>>>>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>>>>> page for each release and we can create documentation per release.
>>>>>>> However, if we start to release the modules individually things get a
>>>>>>> bit more complicated. One possibility is to move from one common
>>>>>>> download page to a download page per module.
>>>>>> That would be OK if they were truly independent. I've drawn here the
>>>>>> dependencies that I observed when I was testing the 0.2-snapshot
>>>>>> release.
>>>>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>>>>> The relationships indicated in the picture just show what happened when
>>>>>> I tried to build something - so for example, the jpa build failed with
>>>>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>>>>> testsupport and parent.
>>>>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>>>>> version will depend on some API currently provided by some version of
>>>>> the quiesce module. The JPA does not care, who actually provides the
>>>>> API, as long as its there.
>>>>> 
>>>>> Thus built-time and deployment-time dependencies are not the same in the
>>>>> OSGi world.
>>>>> 
>>>>>>> 3) Are there other benefits in keeping the module versions consistent
>>>>>>> and concurrently releasing all modules rather than individual modules
>>>>>>> that we haven't really considered? I'm thinking about things like
>>>>>>> documentation, test validation, and samples.
>>>>>> The main point of the blog sample is to bring together a number of the
>>>>>> modules and show them working in one application, I think this might be
>>>>>> true of ariestrader too. Trying to think about how to maintain either of
>>>>>> these samples to work with a set of independently released modules is
>>>>>> making my head hurt.
>>>>>>> Thinking more about #3 - It seems it might be very difficult to
>>>>>>> maintain our documentation and samples once the module versions begin
>>>>>>> to diverge. Changes to one module might force us to want to release
>>>>>>> or update some other module, ... such as the case with (and perhaps
>>>>>>> only with) samples. In fact, samples might be impacted by the release
>>>>>>> of each module if we want to try to keep them as current as possible.
>>>>>>> This might result in a proliferation of sample releases. Moreover,
>>>>>>> the combination of modules/versions we use in our sample releases
>>>>>>> might not demonstrate or validate a common set of modules/versions
>>>>>>> that a user might choose. Yes, all valid versions based upon
>>>>>>> dependencies *should* work fine together ... but that assumes nobody
>>>>>>> makes mistakes. There is a certain comfort (from a user perspective)
>>>>>>> in knowing that a particular set of modules has been tested together
>>>>>>> in some fashion which can at least be partially demonstrated in our
>>>>>>> samples.
>>>>>> I agree.
>>>>>>> I understand why we started down the path of individual components and
>>>>>>> I definitely agree that it has value ... I'm just rethinking the
>>>>>>> decision now that we are doing our second release and have to deal
>>>>>>> with multiple versions for the first time. The second release begins
>>>>>>> to set the precedent for how we deal with some of these things. The
>>>>>>> fact that we basically released everything again with a consistent
>>>>>>> version makes me wonder if that should be our standard process instead
>>>>>>> of individual component versions.
>>>>>> There are advantages in being able to release a module separately. For
>>>>>> example if we find something we need to fix in one module, and it's a
>>>>>> self contained fix, we could create a new release of that module quite
>>>>>> quickly. On the other hand, the slow part of the release process (72
>>>>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>>>>> same.
>>>>> Yeah, sure that may seem a problem (but there is a reason for this,
>>>>> though). But this should influence the decision of whether to do
>>>>> single-module releases or not.
>>>>> 
>>>>>> On balance I'm in favour of a single release at a set level - however -
>>>>>> if we can find an absolutely crystal clear way to document a
>>>>>> release-by-module system I think it could work; I'm worried by the
>>>>>> complexity it would lead to in documentation and samples.
>>>>> I fear you worry on the wrong end of the story. Worry about the
>>>>> interfaces between your modules and look at what the modules really
>>>>> need. Your modules depend on services and API; they don't depend on
>>>>> other modules.
>>>>> 
>>>>> At one point in time you will realize that you have some modules which
>>>>> are mostly stable and some modules which are under heavy development. So
>>>>> you will release the moving parts (modules under development) and not
>>>>> release the static parts.
>>>>> 
>>>>> Doing module releases also enables you to "release early, release often".
>>>>> 
>>>>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>>>>> about.
>>>>> 
>>>>> Regards
>>>>> Felix
>>>>> 
>>>>>> Zoë
>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> --
>>> Joe
>>  		 	   		
> 

Re: release process questions around versions

[zoe slattery <zo...@gmail.com>]

  On 23/08/2010 16:51, Timothy Ward wrote:
> Hi all,
>
> I also agree that we need a process by which modules can be released independently from one another. I do, however, think that this should not occur until we are ready to declare a set of modules as a 1.0 release. There are several common utilities and inter-module dependencies that will be very difficult to formalize until release 1.0, particularly because at the moment we do not strictly apply versioning rules to our packages.
Yes - I think that's the short summary of where we are.

I spent some time thinking about what would have to change in our 
development process when we release by module. There are problems that I 
don't know how to solve, but maybe someone else does. Here is one of them:

It is really important that people can build our released source code 
without having to modify the poms. Consider this example - at the moment 
the candidate release pom.xml in the JPA has dependencies which look 
like this:

<dependency>
<groupId>org.apache.aries</groupId>
<artifactId>org.apache.aries.util</artifactId>
<version>0.2-incubating</version>
</dependency>

So, we would need to have released a 0.2-incubating level of 
org.apache.aries.util before (or at the same time as) the 0.2 incubating 
level of blueprint.

I think this means that we need to change all the projects in trunk to 
depend on released versions of other projects. So a 
0.3-incubating-SNAPSHOT version of JPA in trunk would have this in it's 
pom.xml

<dependency>
<groupId>org.apache.aries</groupId>
<artifactId>org.apache.aries.util</artifactId>
<version>0.2-incubating</version>
</dependency>

This means that we will not be testing the development versions of other 
projects - which is fine as long as they don't change.

What would happen in this scenario when a util developer introduced an 
API breaking change in trunk? Surely the development (trunk) version of 
JPA should be modified to depend on the new version of util which is 
under development? How would the JPA maintainer know this had to happen? 
Is there any tooling to automate it?

I think we need answers to these, and some similar more involved 
questions about samples and docs, before we can switch to a module based 
release.

Zoe

> Regards,
>
> Tim
>
> ----------------------------------------
>> Date: Mon, 23 Aug 2010 11:08:15 -0400
>> From: joebohn@gmail.com
>> To: aries-dev@incubator.apache.org
>> Subject: Re: release process questions around versions
>>
>>
>> Thanks Zoe and Felix.
>>
>> I too agree that Felix raises a number of very good points and I also
>> believe that we should be striving to release individual modules - it's
>> only right and consistent to do so. It's just that our process doesn't
>> currently support this well and things like samples get a little messy.
>> Thank you too Felix for the pointers to the Sling links - we need to
>> look into this more carefully to learn from your experience.
>>
>> So, I think we have two slightly conflicting goals that we are trying to
>> achieve.
>>
>> 1) We'd like to release individual modules on individual schedules as
>> necessary. We need to update our process to accommodate this goal.
>>
>> 2) While independent, our modules can also work together in concert to
>> enable enterprise OSGi applications. As such we would like to
>> demonstrate them working together and make it easy for a user to do the
>> same.
>>
>> My original note was primarily to highlight the problem and start a
>> discussion. I also did a little "thinking out loud" and perhaps lapsed
>> into a bit of monolithic thinking near the end - longing for a more
>> simple solution. That probably isn't the best approach. We should be
>> able to do something to accomplish both goals - perhaps following
>> Sling's lead.
>>
>> Thanks,
>> Joe
>>
>>
>> On 8/23/10 10:11 AM, zoe slattery wrote:
>>> Felix - thanks. You make some good points. Our current problem is that
>>> our development and release process isn't (unlike Felix) a mature
>>> process and currently is not designed to facilitate releasing by module.
>>>
>>> If we go this way we need we need to work through some changes and
>>> everyone who contributes need to understand them :-)
>>>
>>> Thanks again, Zoë
>>>
>>>> Hi,
>>>>
>>>> Sorry to bother from the outside: But, isn't this a project build OSGi
>>>> bundles ?
>>>>
>>>> So I suggest you stop thinking in traditional, monolithic application
>>>> terms, where everything always is built and glued together at the same
>>>> time.
>>>>
>>>> In the OSGi world this is fundamentally different: Parts of the
>>>> application are built at build-time and glued together at deployment
>>>> time.
>>>>
>>>> This is a big plus to your users in that they don't have to always
>>>> update the complete application just in case of a small fix.
>>>>
>>>> It is adding more to the developer's task, but rightly so: You, the
>>>> developer, are fully in charge to ensure compatibility of your module.
>>>> This is what "API" is all about.
>>>>
>>>> Try it, and you will start to enjoy it; really !
>>>>
>>>> On 22.08.2010 11:03, zoe slattery wrote:
>>>>> I agree that this needs some rethinking in the light of experience.
>>>>>> We're in the process of releasing our second set of modules. This
>>>>>> sheds new light on the module version and release process discussions
>>>>>> we had earlier. It also raises some questions about how we ideally
>>>>>> want to handle certain scenarios now that we are forced to deal with
>>>>>> more than one release.
>>>>>>
>>>>>> 1) Should the first release of a new module use the prevailing version
>>>>>> at the time or do we intend to always start with the logical "1" of a
>>>>>> first release? For quiesce we used the prevailing version -
>>>>>> 0.2-incubating.
>>>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>>>> there needs to be some guidance for developers because I don't think
>>>>> it's obvious.
>>>>>
>>>>> At the same time as introducing quiesce, changes were made to jpa -
>>>>> which now depends on quiesce. So, if we were releasing jpa at
>>>>> 0.2-incubating it would need to depend on a release of quiesce created
>>>>> at the same time and called 0.1-incubating.
>>>> Version numbers of modules identify the development history of a single
>>>> module. Lets keep it that simple. Don't overlay this semantic with the
>>>> semantic of the version of the complete application. This ain't gonna
>>>> work in the not so far future. See
>>>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>>>
>>>>>> 2) How will we make multiple component versions available in the
>>>>>> future for download? If we always release all modules (as we did in
>>>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>>>> page for each release and we can create documentation per release.
>>>>>> However, if we start to release the modules individually things get a
>>>>>> bit more complicated. One possibility is to move from one common
>>>>>> download page to a download page per module.
>>>>> That would be OK if they were truly independent. I've drawn here the
>>>>> dependencies that I observed when I was testing the 0.2-snapshot
>>>>> release.
>>>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>>>> The relationships indicated in the picture just show what happened when
>>>>> I tried to build something - so for example, the jpa build failed with
>>>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>>>> testsupport and parent.
>>>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>>>> version will depend on some API currently provided by some version of
>>>> the quiesce module. The JPA does not care, who actually provides the
>>>> API, as long as its there.
>>>>
>>>> Thus built-time and deployment-time dependencies are not the same in the
>>>> OSGi world.
>>>>
>>>>>> 3) Are there other benefits in keeping the module versions consistent
>>>>>> and concurrently releasing all modules rather than individual modules
>>>>>> that we haven't really considered? I'm thinking about things like
>>>>>> documentation, test validation, and samples.
>>>>> The main point of the blog sample is to bring together a number of the
>>>>> modules and show them working in one application, I think this might be
>>>>> true of ariestrader too. Trying to think about how to maintain either of
>>>>> these samples to work with a set of independently released modules is
>>>>> making my head hurt.
>>>>>> Thinking more about #3 - It seems it might be very difficult to
>>>>>> maintain our documentation and samples once the module versions begin
>>>>>> to diverge. Changes to one module might force us to want to release
>>>>>> or update some other module, ... such as the case with (and perhaps
>>>>>> only with) samples. In fact, samples might be impacted by the release
>>>>>> of each module if we want to try to keep them as current as possible.
>>>>>> This might result in a proliferation of sample releases. Moreover,
>>>>>> the combination of modules/versions we use in our sample releases
>>>>>> might not demonstrate or validate a common set of modules/versions
>>>>>> that a user might choose. Yes, all valid versions based upon
>>>>>> dependencies *should* work fine together ... but that assumes nobody
>>>>>> makes mistakes. There is a certain comfort (from a user perspective)
>>>>>> in knowing that a particular set of modules has been tested together
>>>>>> in some fashion which can at least be partially demonstrated in our
>>>>>> samples.
>>>>> I agree.
>>>>>> I understand why we started down the path of individual components and
>>>>>> I definitely agree that it has value ... I'm just rethinking the
>>>>>> decision now that we are doing our second release and have to deal
>>>>>> with multiple versions for the first time. The second release begins
>>>>>> to set the precedent for how we deal with some of these things. The
>>>>>> fact that we basically released everything again with a consistent
>>>>>> version makes me wonder if that should be our standard process instead
>>>>>> of individual component versions.
>>>>> There are advantages in being able to release a module separately. For
>>>>> example if we find something we need to fix in one module, and it's a
>>>>> self contained fix, we could create a new release of that module quite
>>>>> quickly. On the other hand, the slow part of the release process (72
>>>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>>>> same.
>>>> Yeah, sure that may seem a problem (but there is a reason for this,
>>>> though). But this should influence the decision of whether to do
>>>> single-module releases or not.
>>>>
>>>>> On balance I'm in favour of a single release at a set level - however -
>>>>> if we can find an absolutely crystal clear way to document a
>>>>> release-by-module system I think it could work; I'm worried by the
>>>>> complexity it would lead to in documentation and samples.
>>>> I fear you worry on the wrong end of the story. Worry about the
>>>> interfaces between your modules and look at what the modules really
>>>> need. Your modules depend on services and API; they don't depend on
>>>> other modules.
>>>>
>>>> At one point in time you will realize that you have some modules which
>>>> are mostly stable and some modules which are under heavy development. So
>>>> you will release the moving parts (modules under development) and not
>>>> release the static parts.
>>>>
>>>> Doing module releases also enables you to "release early, release often".
>>>>
>>>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>>>> about.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> Zoë
>>>>>
>>>>>
>>>
>>
>> --
>> Joe
>   		 	   		

RE: release process questions around versions

[Timothy Ward <ti...@hotmail.com>]

Hi all,

I also agree that we need a process by which modules can be released independently from one another. I do, however, think that this should not occur until we are ready to declare a set of modules as a 1.0 release. There are several common utilities and inter-module dependencies that will be very difficult to formalize until release 1.0, particularly because at the moment we do not strictly apply versioning rules to our packages.

Regards,

Tim

----------------------------------------
> Date: Mon, 23 Aug 2010 11:08:15 -0400
> From: joebohn@gmail.com
> To: aries-dev@incubator.apache.org
> Subject: Re: release process questions around versions
>
>
> Thanks Zoe and Felix.
>
> I too agree that Felix raises a number of very good points and I also
> believe that we should be striving to release individual modules - it's
> only right and consistent to do so. It's just that our process doesn't
> currently support this well and things like samples get a little messy.
> Thank you too Felix for the pointers to the Sling links - we need to
> look into this more carefully to learn from your experience.
>
> So, I think we have two slightly conflicting goals that we are trying to
> achieve.
>
> 1) We'd like to release individual modules on individual schedules as
> necessary. We need to update our process to accommodate this goal.
>
> 2) While independent, our modules can also work together in concert to
> enable enterprise OSGi applications. As such we would like to
> demonstrate them working together and make it easy for a user to do the
> same.
>
> My original note was primarily to highlight the problem and start a
> discussion. I also did a little "thinking out loud" and perhaps lapsed
> into a bit of monolithic thinking near the end - longing for a more
> simple solution. That probably isn't the best approach. We should be
> able to do something to accomplish both goals - perhaps following
> Sling's lead.
>
> Thanks,
> Joe
>
>
> On 8/23/10 10:11 AM, zoe slattery wrote:
>> Felix - thanks. You make some good points. Our current problem is that
>> our development and release process isn't (unlike Felix) a mature
>> process and currently is not designed to facilitate releasing by module.
>>
>> If we go this way we need we need to work through some changes and
>> everyone who contributes need to understand them :-)
>>
>> Thanks again, Zoë
>>
>>> Hi,
>>>
>>> Sorry to bother from the outside: But, isn't this a project build OSGi
>>> bundles ?
>>>
>>> So I suggest you stop thinking in traditional, monolithic application
>>> terms, where everything always is built and glued together at the same
>>> time.
>>>
>>> In the OSGi world this is fundamentally different: Parts of the
>>> application are built at build-time and glued together at deployment
>>> time.
>>>
>>> This is a big plus to your users in that they don't have to always
>>> update the complete application just in case of a small fix.
>>>
>>> It is adding more to the developer's task, but rightly so: You, the
>>> developer, are fully in charge to ensure compatibility of your module.
>>> This is what "API" is all about.
>>>
>>> Try it, and you will start to enjoy it; really !
>>>
>>> On 22.08.2010 11:03, zoe slattery wrote:
>>>> I agree that this needs some rethinking in the light of experience.
>>>>> We're in the process of releasing our second set of modules. This
>>>>> sheds new light on the module version and release process discussions
>>>>> we had earlier. It also raises some questions about how we ideally
>>>>> want to handle certain scenarios now that we are forced to deal with
>>>>> more than one release.
>>>>>
>>>>> 1) Should the first release of a new module use the prevailing version
>>>>> at the time or do we intend to always start with the logical "1" of a
>>>>> first release? For quiesce we used the prevailing version -
>>>>> 0.2-incubating.
>>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>>> there needs to be some guidance for developers because I don't think
>>>> it's obvious.
>>>>
>>>> At the same time as introducing quiesce, changes were made to jpa -
>>>> which now depends on quiesce. So, if we were releasing jpa at
>>>> 0.2-incubating it would need to depend on a release of quiesce created
>>>> at the same time and called 0.1-incubating.
>>> Version numbers of modules identify the development history of a single
>>> module. Lets keep it that simple. Don't overlay this semantic with the
>>> semantic of the version of the complete application. This ain't gonna
>>> work in the not so far future. See
>>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>>
>>>>> 2) How will we make multiple component versions available in the
>>>>> future for download? If we always release all modules (as we did in
>>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>>> page for each release and we can create documentation per release.
>>>>> However, if we start to release the modules individually things get a
>>>>> bit more complicated. One possibility is to move from one common
>>>>> download page to a download page per module.
>>>> That would be OK if they were truly independent. I've drawn here the
>>>> dependencies that I observed when I was testing the 0.2-snapshot
>>>> release.
>>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>>> The relationships indicated in the picture just show what happened when
>>>> I tried to build something - so for example, the jpa build failed with
>>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>>> testsupport and parent.
>>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>>> version will depend on some API currently provided by some version of
>>> the quiesce module. The JPA does not care, who actually provides the
>>> API, as long as its there.
>>>
>>> Thus built-time and deployment-time dependencies are not the same in the
>>> OSGi world.
>>>
>>>>> 3) Are there other benefits in keeping the module versions consistent
>>>>> and concurrently releasing all modules rather than individual modules
>>>>> that we haven't really considered? I'm thinking about things like
>>>>> documentation, test validation, and samples.
>>>> The main point of the blog sample is to bring together a number of the
>>>> modules and show them working in one application, I think this might be
>>>> true of ariestrader too. Trying to think about how to maintain either of
>>>> these samples to work with a set of independently released modules is
>>>> making my head hurt.
>>>>> Thinking more about #3 - It seems it might be very difficult to
>>>>> maintain our documentation and samples once the module versions begin
>>>>> to diverge. Changes to one module might force us to want to release
>>>>> or update some other module, ... such as the case with (and perhaps
>>>>> only with) samples. In fact, samples might be impacted by the release
>>>>> of each module if we want to try to keep them as current as possible.
>>>>> This might result in a proliferation of sample releases. Moreover,
>>>>> the combination of modules/versions we use in our sample releases
>>>>> might not demonstrate or validate a common set of modules/versions
>>>>> that a user might choose. Yes, all valid versions based upon
>>>>> dependencies *should* work fine together ... but that assumes nobody
>>>>> makes mistakes. There is a certain comfort (from a user perspective)
>>>>> in knowing that a particular set of modules has been tested together
>>>>> in some fashion which can at least be partially demonstrated in our
>>>>> samples.
>>>> I agree.
>>>>> I understand why we started down the path of individual components and
>>>>> I definitely agree that it has value ... I'm just rethinking the
>>>>> decision now that we are doing our second release and have to deal
>>>>> with multiple versions for the first time. The second release begins
>>>>> to set the precedent for how we deal with some of these things. The
>>>>> fact that we basically released everything again with a consistent
>>>>> version makes me wonder if that should be our standard process instead
>>>>> of individual component versions.
>>>> There are advantages in being able to release a module separately. For
>>>> example if we find something we need to fix in one module, and it's a
>>>> self contained fix, we could create a new release of that module quite
>>>> quickly. On the other hand, the slow part of the release process (72
>>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>>> same.
>>> Yeah, sure that may seem a problem (but there is a reason for this,
>>> though). But this should influence the decision of whether to do
>>> single-module releases or not.
>>>
>>>> On balance I'm in favour of a single release at a set level - however -
>>>> if we can find an absolutely crystal clear way to document a
>>>> release-by-module system I think it could work; I'm worried by the
>>>> complexity it would lead to in documentation and samples.
>>> I fear you worry on the wrong end of the story. Worry about the
>>> interfaces between your modules and look at what the modules really
>>> need. Your modules depend on services and API; they don't depend on
>>> other modules.
>>>
>>> At one point in time you will realize that you have some modules which
>>> are mostly stable and some modules which are under heavy development. So
>>> you will release the moving parts (modules under development) and not
>>> release the static parts.
>>>
>>> Doing module releases also enables you to "release early, release often".
>>>
>>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>>> about.
>>>
>>> Regards
>>> Felix
>>>
>>>> Zoë
>>>>
>>>>
>>>
>>
>>
>
>
> --
> Joe
 		 	   		  

Re: release process questions around versions

[Joe Bohn <jo...@gmail.com>]

Thanks Zoe and Felix.

I too agree that Felix raises a number of very good points and I also 
believe that we should be striving to release individual modules - it's 
only right and consistent to do so.  It's just that our process doesn't 
currently support this well and things like samples get a little messy. 
   Thank you too Felix for the pointers to the Sling links - we need to 
look into this more carefully to learn from your experience.

So, I think we have two slightly conflicting goals that we are trying to 
achieve.

1)  We'd like to release individual modules on individual schedules as 
necessary.   We need to update our process to accommodate this goal.

2)  While independent, our modules can also work together in concert to 
enable enterprise OSGi applications.   As such we would like to 
demonstrate them working together and make it easy for a user to do the 
same.

My original note was primarily to highlight the problem and start a 
discussion.  I also did a little "thinking out loud" and perhaps lapsed 
into a bit of monolithic thinking near the end - longing for a more 
simple solution.  That probably isn't the best approach.  We should be 
able to do something to accomplish both goals - perhaps following 
Sling's lead.

Thanks,
Joe


On 8/23/10 10:11 AM, zoe slattery wrote:
> Felix - thanks. You make some good points. Our current problem is that
> our development and release process isn't (unlike Felix) a mature
> process and currently is not designed to facilitate releasing by module.
>
> If we go this way we need we need to work through some changes and
> everyone who contributes need to understand them :-)
>
> Thanks again, Zoë
>
>> Hi,
>>
>> Sorry to bother from the outside: But, isn't this a project build OSGi
>> bundles ?
>>
>> So I suggest you stop thinking in traditional, monolithic application
>> terms, where everything always is built and glued together at the same
>> time.
>>
>> In the OSGi world this is fundamentally different: Parts of the
>> application are built at build-time and glued together at deployment
>> time.
>>
>> This is a big plus to your users in that they don't have to always
>> update the complete application just in case of a small fix.
>>
>> It is adding more to the developer's task, but rightly so: You, the
>> developer, are fully in charge to ensure compatibility of your module.
>> This is what "API" is all about.
>>
>> Try it, and you will start to enjoy it; really !
>>
>> On 22.08.2010 11:03, zoe slattery wrote:
>>> I agree that this needs some rethinking in the light of experience.
>>>> We're in the process of releasing our second set of modules. This
>>>> sheds new light on the module version and release process discussions
>>>> we had earlier. It also raises some questions about how we ideally
>>>> want to handle certain scenarios now that we are forced to deal with
>>>> more than one release.
>>>>
>>>> 1) Should the first release of a new module use the prevailing version
>>>> at the time or do we intend to always start with the logical "1" of a
>>>> first release? For quiesce we used the prevailing version -
>>>> 0.2-incubating.
>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>> there needs to be some guidance for developers because I don't think
>>> it's obvious.
>>>
>>> At the same time as introducing quiesce, changes were made to jpa -
>>> which now depends on quiesce. So, if we were releasing jpa at
>>> 0.2-incubating it would need to depend on a release of quiesce created
>>> at the same time and called 0.1-incubating.
>> Version numbers of modules identify the development history of a single
>> module. Lets keep it that simple. Don't overlay this semantic with the
>> semantic of the version of the complete application. This ain't gonna
>> work in the not so far future. See
>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>
>>>> 2) How will we make multiple component versions available in the
>>>> future for download? If we always release all modules (as we did in
>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>> page for each release and we can create documentation per release.
>>>> However, if we start to release the modules individually things get a
>>>> bit more complicated. One possibility is to move from one common
>>>> download page to a download page per module.
>>> That would be OK if they were truly independent. I've drawn here the
>>> dependencies that I observed when I was testing the 0.2-snapshot
>>> release.
>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>> The relationships indicated in the picture just show what happened when
>>> I tried to build something - so for example, the jpa build failed with
>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>> testsupport and parent.
>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>> version will depend on some API currently provided by some version of
>> the quiesce module. The JPA does not care, who actually provides the
>> API, as long as its there.
>>
>> Thus built-time and deployment-time dependencies are not the same in the
>> OSGi world.
>>
>>>> 3) Are there other benefits in keeping the module versions consistent
>>>> and concurrently releasing all modules rather than individual modules
>>>> that we haven't really considered? I'm thinking about things like
>>>> documentation, test validation, and samples.
>>> The main point of the blog sample is to bring together a number of the
>>> modules and show them working in one application, I think this might be
>>> true of ariestrader too. Trying to think about how to maintain either of
>>> these samples to work with a set of independently released modules is
>>> making my head hurt.
>>>> Thinking more about #3 - It seems it might be very difficult to
>>>> maintain our documentation and samples once the module versions begin
>>>> to diverge. Changes to one module might force us to want to release
>>>> or update some other module, ... such as the case with (and perhaps
>>>> only with) samples. In fact, samples might be impacted by the release
>>>> of each module if we want to try to keep them as current as possible.
>>>> This might result in a proliferation of sample releases. Moreover,
>>>> the combination of modules/versions we use in our sample releases
>>>> might not demonstrate or validate a common set of modules/versions
>>>> that a user might choose. Yes, all valid versions based upon
>>>> dependencies *should* work fine together ... but that assumes nobody
>>>> makes mistakes. There is a certain comfort (from a user perspective)
>>>> in knowing that a particular set of modules has been tested together
>>>> in some fashion which can at least be partially demonstrated in our
>>>> samples.
>>> I agree.
>>>> I understand why we started down the path of individual components and
>>>> I definitely agree that it has value ... I'm just rethinking the
>>>> decision now that we are doing our second release and have to deal
>>>> with multiple versions for the first time. The second release begins
>>>> to set the precedent for how we deal with some of these things. The
>>>> fact that we basically released everything again with a consistent
>>>> version makes me wonder if that should be our standard process instead
>>>> of individual component versions.
>>> There are advantages in being able to release a module separately. For
>>> example if we find something we need to fix in one module, and it's a
>>> self contained fix, we could create a new release of that module quite
>>> quickly. On the other hand, the slow part of the release process (72
>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>> same.
>> Yeah, sure that may seem a problem (but there is a reason for this,
>> though). But this should influence the decision of whether to do
>> single-module releases or not.
>>
>>> On balance I'm in favour of a single release at a set level - however -
>>> if we can find an absolutely crystal clear way to document a
>>> release-by-module system I think it could work; I'm worried by the
>>> complexity it would lead to in documentation and samples.
>> I fear you worry on the wrong end of the story. Worry about the
>> interfaces between your modules and look at what the modules really
>> need. Your modules depend on services and API; they don't depend on
>> other modules.
>>
>> At one point in time you will realize that you have some modules which
>> are mostly stable and some modules which are under heavy development. So
>> you will release the moving parts (modules under development) and not
>> release the static parts.
>>
>> Doing module releases also enables you to "release early, release often".
>>
>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>> about.
>>
>> Regards
>> Felix
>>
>>> Zoë
>>>
>>>
>>
>
>


-- 
Joe

Re: release process questions around versions

[Felix Meschberger <fm...@gmail.com>]

Hi,

I understand this is an ongoing process.

But it is more important to know where you are heading and start going
there. Instead of just saying "we are here, so we can go nowhere".  ;-)

On 23.08.2010 16:11, zoe slattery wrote:
>  Felix - thanks. You make some good points. Our current problem is that
> our development and release process isn't (unlike Felix) a mature
> process and currently is not designed to facilitate releasing by module.
> 
> If we go this way we need we need to work through some changes and
> everyone who contributes need to understand them :-)

Oh, yes. It is definitely not only a technical issue. It is also an
issue of education and getting used to it.

Go for it and, most of, ĥave fun ;-)

Regards
Felix

> 
> Thanks again, Zoë
> 
>> Hi,
>>
>> Sorry to bother from the outside: But, isn't this a project build OSGi
>> bundles ?
>>
>> So I suggest you stop thinking in traditional, monolithic application
>> terms, where everything always is built and glued together at the same
>> time.
>>
>> In the OSGi world this is fundamentally different: Parts of the
>> application are built at build-time and glued together at deployment
>> time.
>>
>> This is a big plus to your users in that they don't have to always
>> update the complete application just in case of a small fix.
>>
>> It is adding more to the developer's task, but rightly so: You, the
>> developer, are fully in charge to ensure compatibility of your module.
>> This is what "API" is all about.
>>
>> Try it, and you will start to enjoy it; really !
>>
>> On 22.08.2010 11:03, zoe slattery wrote:
>>> I agree that this needs some rethinking in the light of experience.
>>>> We're in the process of releasing our second set of modules.  This
>>>> sheds new light on the module version and release process discussions
>>>> we had earlier.  It also raises some questions about how we ideally
>>>> want to handle certain scenarios now that we are forced to deal with
>>>> more than one release.
>>>>
>>>> 1) Should the first release of a new module use the prevailing version
>>>> at the time or do we intend to always start with the logical "1" of a
>>>> first release?  For quiesce we used the prevailing version -
>>>> 0.2-incubating.
>>> If we had released quiesce at 0.1-incubating I guess that it should have
>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>>> there needs to be some guidance for developers because I don't think
>>> it's obvious.
>>>
>>> At the same time as introducing quiesce, changes were made to jpa -
>>> which now depends on quiesce. So, if we were releasing jpa at
>>> 0.2-incubating it would need to depend on a release of quiesce created
>>> at the same time and called 0.1-incubating.
>> Version numbers of modules identify the development history of a single
>> module. Lets keep it that simple. Don't overlay this semantic with the
>> semantic of the version of the complete application. This ain't gonna
>> work in the not so far future. See
>> http://wiki.eclipse.org/index.php/Version_Numbering.
>>
>>>> 2) How will we make multiple component versions available in the
>>>> future for download?  If we always release all modules (as we did in
>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>>> page for each release and we can create documentation per release.
>>>> However, if we start to release the modules individually things get a
>>>> bit more complicated.  One possibility is to move from one common
>>>> download page to a download page per module.
>>> That would be OK if they were truly independent. I've drawn here the
>>> dependencies that I observed when I was testing the 0.2-snapshot
>>> release.
>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>>> The relationships indicated in the picture just show what happened when
>>> I tried to build something - so for example, the jpa build failed with
>>> missing dependencies until I had 'mvn install'd quiesce, util,
>>> testsupport and parent.
>> Just keep in mind, that for deployment, your jpa 0.2-incubator module
>> version will depend on some API currently provided by some version of
>> the quiesce module. The JPA does not care, who actually provides the
>> API, as long as its there.
>>
>> Thus built-time and deployment-time dependencies are not the same in the
>> OSGi world.
>>
>>>> 3) Are there other benefits in keeping the module versions consistent
>>>> and concurrently releasing all modules rather than individual modules
>>>> that we haven't really considered?  I'm thinking about things like
>>>> documentation, test validation, and samples.
>>> The main point of the blog sample is to bring together a number of the
>>> modules and show them working in one application, I think this might be
>>> true of ariestrader too. Trying to think about how to maintain either of
>>> these samples to work with a set of independently released modules is
>>> making my head hurt.
>>>> Thinking more about #3 - It seems it might be very difficult to
>>>> maintain our documentation and samples once the module versions begin
>>>> to diverge.  Changes to one module might force us to want to release
>>>> or update some other module, ... such as the case with (and perhaps
>>>> only with) samples.  In fact, samples might be impacted by the release
>>>> of each module if we want to try to keep them as current as possible.
>>>> This might result in a proliferation of sample releases.  Moreover,
>>>> the combination of modules/versions we use in our sample releases
>>>> might not demonstrate or validate a common set of modules/versions
>>>> that a user might choose. Yes, all valid versions based upon
>>>> dependencies *should* work fine together ... but that assumes nobody
>>>> makes mistakes.  There is a certain comfort (from a user perspective)
>>>> in knowing that a particular set of modules has been tested together
>>>> in some fashion which can at least be partially demonstrated in our
>>>> samples.
>>> I agree.
>>>> I understand why we started down the path of individual components and
>>>> I definitely agree that it has value ... I'm just rethinking the
>>>> decision now that we are doing our second release and have to deal
>>>> with multiple versions for the first time.  The second release begins
>>>> to set the precedent for how we deal with some of these things.  The
>>>> fact that we basically released everything again with a consistent
>>>> version makes me wonder if that should be our standard process instead
>>>> of individual component versions.
>>> There are  advantages in being able to release a module separately. For
>>> example if we find something we need to fix in one module, and it's a
>>> self contained fix, we could create  a new release of that module quite
>>> quickly. On the other hand, the slow part of the release process (72
>>> hours for a vote, then another 72 for the incubator PMC?) remains the
>>> same.
>> Yeah, sure that may seem a problem (but there is a reason for this,
>> though). But this should influence the decision of whether to do
>> single-module releases or not.
>>
>>> On balance I'm in favour of a single release at a set level - however -
>>> if we can find an absolutely crystal clear way to document a
>>> release-by-module system I think it could work; I'm worried by the
>>> complexity it would lead to in documentation and samples.
>> I fear you worry on the wrong end of the story. Worry about the
>> interfaces between your modules and look at what the modules really
>> need. Your modules depend on services and API; they don't depend on
>> other modules.
>>
>> At one point in time you will realize that you have some modules which
>> are mostly stable and some modules which are under heavy development. So
>> you will release the moving parts (modules under development) and not
>> release the static parts.
>>
>> Doing module releases also enables you to "release early, release often".
>>
>> Try it, enjoy it. For me this is what OSGi is mostly and almost all
>> about.
>>
>> Regards
>> Felix
>>
>>> Zoë
>>>
>>>
>>
> 
> 

Re: release process questions around versions

[zoe slattery <zo...@gmail.com>]

  Felix - thanks. You make some good points. Our current problem is that 
our development and release process isn't (unlike Felix) a mature 
process and currently is not designed to facilitate releasing by module.

If we go this way we need we need to work through some changes and 
everyone who contributes need to understand them :-)

Thanks again, Zoë

> Hi,
>
> Sorry to bother from the outside: But, isn't this a project build OSGi
> bundles ?
>
> So I suggest you stop thinking in traditional, monolithic application
> terms, where everything always is built and glued together at the same time.
>
> In the OSGi world this is fundamentally different: Parts of the
> application are built at build-time and glued together at deployment time.
>
> This is a big plus to your users in that they don't have to always
> update the complete application just in case of a small fix.
>
> It is adding more to the developer's task, but rightly so: You, the
> developer, are fully in charge to ensure compatibility of your module.
> This is what "API" is all about.
>
> Try it, and you will start to enjoy it; really !
>
> On 22.08.2010 11:03, zoe slattery wrote:
>> I agree that this needs some rethinking in the light of experience.
>>> We're in the process of releasing our second set of modules.  This
>>> sheds new light on the module version and release process discussions
>>> we had earlier.  It also raises some questions about how we ideally
>>> want to handle certain scenarios now that we are forced to deal with
>>> more than one release.
>>>
>>> 1) Should the first release of a new module use the prevailing version
>>> at the time or do we intend to always start with the logical "1" of a
>>> first release?  For quiesce we used the prevailing version -
>>> 0.2-incubating.
>> If we had released quiesce at 0.1-incubating I guess that it should have
>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
>> there needs to be some guidance for developers because I don't think
>> it's obvious.
>>
>> At the same time as introducing quiesce, changes were made to jpa -
>> which now depends on quiesce. So, if we were releasing jpa at
>> 0.2-incubating it would need to depend on a release of quiesce created
>> at the same time and called 0.1-incubating.
> Version numbers of modules identify the development history of a single
> module. Lets keep it that simple. Don't overlay this semantic with the
> semantic of the version of the complete application. This ain't gonna
> work in the not so far future. See
> http://wiki.eclipse.org/index.php/Version_Numbering.
>
>>> 2) How will we make multiple component versions available in the
>>> future for download?  If we always release all modules (as we did in
>>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>>> page for each release and we can create documentation per release.
>>> However, if we start to release the modules individually things get a
>>> bit more complicated.  One possibility is to move from one common
>>> download page to a download page per module.
>> That would be OK if they were truly independent. I've drawn here the
>> dependencies that I observed when I was testing the 0.2-snapshot
>> release.
>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
>> The relationships indicated in the picture just show what happened when
>> I tried to build something - so for example, the jpa build failed with
>> missing dependencies until I had 'mvn install'd quiesce, util,
>> testsupport and parent.
> Just keep in mind, that for deployment, your jpa 0.2-incubator module
> version will depend on some API currently provided by some version of
> the quiesce module. The JPA does not care, who actually provides the
> API, as long as its there.
>
> Thus built-time and deployment-time dependencies are not the same in the
> OSGi world.
>
>>> 3) Are there other benefits in keeping the module versions consistent
>>> and concurrently releasing all modules rather than individual modules
>>> that we haven't really considered?  I'm thinking about things like
>>> documentation, test validation, and samples.
>> The main point of the blog sample is to bring together a number of the
>> modules and show them working in one application, I think this might be
>> true of ariestrader too. Trying to think about how to maintain either of
>> these samples to work with a set of independently released modules is
>> making my head hurt.
>>> Thinking more about #3 - It seems it might be very difficult to
>>> maintain our documentation and samples once the module versions begin
>>> to diverge.  Changes to one module might force us to want to release
>>> or update some other module, ... such as the case with (and perhaps
>>> only with) samples.  In fact, samples might be impacted by the release
>>> of each module if we want to try to keep them as current as possible.
>>> This might result in a proliferation of sample releases.  Moreover,
>>> the combination of modules/versions we use in our sample releases
>>> might not demonstrate or validate a common set of modules/versions
>>> that a user might choose. Yes, all valid versions based upon
>>> dependencies *should* work fine together ... but that assumes nobody
>>> makes mistakes.  There is a certain comfort (from a user perspective)
>>> in knowing that a particular set of modules has been tested together
>>> in some fashion which can at least be partially demonstrated in our
>>> samples.
>> I agree.
>>> I understand why we started down the path of individual components and
>>> I definitely agree that it has value ... I'm just rethinking the
>>> decision now that we are doing our second release and have to deal
>>> with multiple versions for the first time.  The second release begins
>>> to set the precedent for how we deal with some of these things.  The
>>> fact that we basically released everything again with a consistent
>>> version makes me wonder if that should be our standard process instead
>>> of individual component versions.
>> There are  advantages in being able to release a module separately. For
>> example if we find something we need to fix in one module, and it's a
>> self contained fix, we could create  a new release of that module quite
>> quickly. On the other hand, the slow part of the release process (72
>> hours for a vote, then another 72 for the incubator PMC?) remains the same.
> Yeah, sure that may seem a problem (but there is a reason for this,
> though). But this should influence the decision of whether to do
> single-module releases or not.
>
>> On balance I'm in favour of a single release at a set level - however -
>> if we can find an absolutely crystal clear way to document a
>> release-by-module system I think it could work; I'm worried by the
>> complexity it would lead to in documentation and samples.
> I fear you worry on the wrong end of the story. Worry about the
> interfaces between your modules and look at what the modules really
> need. Your modules depend on services and API; they don't depend on
> other modules.
>
> At one point in time you will realize that you have some modules which
> are mostly stable and some modules which are under heavy development. So
> you will release the moving parts (modules under development) and not
> release the static parts.
>
> Doing module releases also enables you to "release early, release often".
>
> Try it, enjoy it. For me this is what OSGi is mostly and almost all about.
>
> Regards
> Felix
>
>> Zoë
>>
>>
>

Re: release process questions around versions

[Felix Meschberger <fm...@gmail.com>]

Hi,

Sorry to bother from the outside: But, isn't this a project build OSGi
bundles ?

So I suggest you stop thinking in traditional, monolithic application
terms, where everything always is built and glued together at the same time.

In the OSGi world this is fundamentally different: Parts of the
application are built at build-time and glued together at deployment time.

This is a big plus to your users in that they don't have to always
update the complete application just in case of a small fix.

It is adding more to the developer's task, but rightly so: You, the
developer, are fully in charge to ensure compatibility of your module.
This is what "API" is all about.

Try it, and you will start to enjoy it; really !

On 22.08.2010 11:03, zoe slattery wrote:
> I agree that this needs some rethinking in the light of experience.
>>
>> We're in the process of releasing our second set of modules.  This
>> sheds new light on the module version and release process discussions
>> we had earlier.  It also raises some questions about how we ideally
>> want to handle certain scenarios now that we are forced to deal with
>> more than one release.
>>
>> 1) Should the first release of a new module use the prevailing version
>> at the time or do we intend to always start with the logical "1" of a
>> first release?  For quiesce we used the prevailing version -
>> 0.2-incubating.
> If we had released quiesce at 0.1-incubating I guess that it should have
> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there
> there needs to be some guidance for developers because I don't think
> it's obvious.
> 
> At the same time as introducing quiesce, changes were made to jpa -
> which now depends on quiesce. So, if we were releasing jpa at
> 0.2-incubating it would need to depend on a release of quiesce created
> at the same time and called 0.1-incubating.

Version numbers of modules identify the development history of a single
module. Lets keep it that simple. Don't overlay this semantic with the
semantic of the version of the complete application. This ain't gonna
work in the not so far future. See
http://wiki.eclipse.org/index.php/Version_Numbering.

>>
>> 2) How will we make multiple component versions available in the
>> future for download?  If we always release all modules (as we did in
>> our 0.1 and 0.2 releases) then it's simple - we can create a download
>> page for each release and we can create documentation per release. 
>> However, if we start to release the modules individually things get a
>> bit more complicated.  One possibility is to move from one common
>> download page to a download page per module.
> That would be OK if they were truly independent. I've drawn here the
> dependencies that I observed when I was testing the 0.2-snapshot
> release.
> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies.
> The relationships indicated in the picture just show what happened when
> I tried to build something - so for example, the jpa build failed with
> missing dependencies until I had 'mvn install'd quiesce, util,
> testsupport and parent.

Just keep in mind, that for deployment, your jpa 0.2-incubator module
version will depend on some API currently provided by some version of
the quiesce module. The JPA does not care, who actually provides the
API, as long as its there.

Thus built-time and deployment-time dependencies are not the same in the
OSGi world.

>>
>> 3) Are there other benefits in keeping the module versions consistent
>> and concurrently releasing all modules rather than individual modules
>> that we haven't really considered?  I'm thinking about things like
>> documentation, test validation, and samples.
> The main point of the blog sample is to bring together a number of the
> modules and show them working in one application, I think this might be
> true of ariestrader too. Trying to think about how to maintain either of
> these samples to work with a set of independently released modules is
> making my head hurt.
>>
>> Thinking more about #3 - It seems it might be very difficult to
>> maintain our documentation and samples once the module versions begin
>> to diverge.  Changes to one module might force us to want to release
>> or update some other module, ... such as the case with (and perhaps
>> only with) samples.  In fact, samples might be impacted by the release
>> of each module if we want to try to keep them as current as possible. 
>> This might result in a proliferation of sample releases.  Moreover,
>> the combination of modules/versions we use in our sample releases
>> might not demonstrate or validate a common set of modules/versions
>> that a user might choose. Yes, all valid versions based upon
>> dependencies *should* work fine together ... but that assumes nobody
>> makes mistakes.  There is a certain comfort (from a user perspective)
>> in knowing that a particular set of modules has been tested together
>> in some fashion which can at least be partially demonstrated in our
>> samples.
> I agree.
>>
>> I understand why we started down the path of individual components and
>> I definitely agree that it has value ... I'm just rethinking the
>> decision now that we are doing our second release and have to deal
>> with multiple versions for the first time.  The second release begins
>> to set the precedent for how we deal with some of these things.  The
>> fact that we basically released everything again with a consistent
>> version makes me wonder if that should be our standard process instead
>> of individual component versions.
> 
> There are  advantages in being able to release a module separately. For
> example if we find something we need to fix in one module, and it's a
> self contained fix, we could create  a new release of that module quite
> quickly. On the other hand, the slow part of the release process (72
> hours for a vote, then another 72 for the incubator PMC?) remains the same.

Yeah, sure that may seem a problem (but there is a reason for this,
though). But this should influence the decision of whether to do
single-module releases or not.

> 
> On balance I'm in favour of a single release at a set level - however -
> if we can find an absolutely crystal clear way to document a
> release-by-module system I think it could work; I'm worried by the
> complexity it would lead to in documentation and samples.

I fear you worry on the wrong end of the story. Worry about the
interfaces between your modules and look at what the modules really
need. Your modules depend on services and API; they don't depend on
other modules.

At one point in time you will realize that you have some modules which
are mostly stable and some modules which are under heavy development. So
you will release the moving parts (modules under development) and not
release the static parts.

Doing module releases also enables you to "release early, release often".

Try it, enjoy it. For me this is what OSGi is mostly and almost all about.

Regards
Felix

> 
> Zoë
> 
> 

Re: release process questions around versions

[zoe slattery <zo...@gmail.com>]

I agree that this needs some rethinking in the light of experience.
>
> We're in the process of releasing our second set of modules.  This 
> sheds new light on the module version and release process discussions 
> we had earlier.  It also raises some questions about how we ideally 
> want to handle certain scenarios now that we are forced to deal with 
> more than one release.
>
> 1) Should the first release of a new module use the prevailing version 
> at the time or do we intend to always start with the logical "1" of a 
> first release?  For quiesce we used the prevailing version - 
> 0.2-incubating.
If we had released quiesce at 0.1-incubating I guess that it should have 
been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there 
there needs to be some guidance for developers because I don't think 
it's obvious.

At the same time as introducing quiesce, changes were made to jpa - 
which now depends on quiesce. So, if we were releasing jpa at 
0.2-incubating it would need to depend on a release of quiesce created 
at the same time and called 0.1-incubating.
>
> 2) How will we make multiple component versions available in the 
> future for download?  If we always release all modules (as we did in 
> our 0.1 and 0.2 releases) then it's simple - we can create a download 
> page for each release and we can create documentation per release.  
> However, if we start to release the modules individually things get a 
> bit more complicated.  One possibility is to move from one common 
> download page to a download page per module.
That would be OK if they were truly independent. I've drawn here the 
dependencies that I observed when I was testing the 0.2-snapshot 
release. 
https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies. 
The relationships indicated in the picture just show what happened when 
I tried to build something - so for example, the jpa build failed with 
missing dependencies until I had 'mvn install'd quiesce, util, 
testsupport and parent.
>
> 3) Are there other benefits in keeping the module versions consistent 
> and concurrently releasing all modules rather than individual modules 
> that we haven't really considered?  I'm thinking about things like 
> documentation, test validation, and samples.
The main point of the blog sample is to bring together a number of the 
modules and show them working in one application, I think this might be 
true of ariestrader too. Trying to think about how to maintain either of 
these samples to work with a set of independently released modules is 
making my head hurt.
>
> Thinking more about #3 - It seems it might be very difficult to 
> maintain our documentation and samples once the module versions begin 
> to diverge.  Changes to one module might force us to want to release 
> or update some other module, ... such as the case with (and perhaps 
> only with) samples.  In fact, samples might be impacted by the release 
> of each module if we want to try to keep them as current as possible.  
> This might result in a proliferation of sample releases.  Moreover, 
> the combination of modules/versions we use in our sample releases 
> might not demonstrate or validate a common set of modules/versions 
> that a user might choose. Yes, all valid versions based upon 
> dependencies *should* work fine together ... but that assumes nobody 
> makes mistakes.  There is a certain comfort (from a user perspective) 
> in knowing that a particular set of modules has been tested together 
> in some fashion which can at least be partially demonstrated in our 
> samples.
I agree.
>
> I understand why we started down the path of individual components and 
> I definitely agree that it has value ... I'm just rethinking the 
> decision now that we are doing our second release and have to deal 
> with multiple versions for the first time.  The second release begins 
> to set the precedent for how we deal with some of these things.  The 
> fact that we basically released everything again with a consistent 
> version makes me wonder if that should be our standard process instead 
> of individual component versions.

There are  advantages in being able to release a module separately. For 
example if we find something we need to fix in one module, and it's a 
self contained fix, we could create  a new release of that module quite 
quickly. On the other hand, the slow part of the release process (72 
hours for a vote, then another 72 for the incubator PMC?) remains the same.

On balance I'm in favour of a single release at a set level - however - 
if we can find an absolutely crystal clear way to document a 
release-by-module system I think it could work; I'm worried by the 
complexity it would lead to in documentation and samples.

Zoë

Re: release process questions around versions

[Felix Meschberger <fm...@gmail.com>]

Hi

Let my post my view of this problem from the outside and as a member of
the Felix and Sling projects.

In Felix we don't have a "global" release. We only have individual
module releases, such as the framework, the webconsole, declarative
services, configuration admin, iPOJO, etc.

This works very well. In fact given the independent nature of these
module, this is probably the only viable way to have regular releases.

In Sling, which resembles a traditional Apache project more that Felix,
we also do single-module releases.

Of course we understand the need of people to be able to grab a
prepackaged version and thus we try to regularly release prepackaged
versions. In contrast to modules, we have a single position counter for
this prepackaged releases. The first rlease was Sling 5 and currently we
are working towards a Sling 6 release.

Point is really, that we are living in a modular world where not
everything can be coordinated to the point of having everything ready
for release at the same time. Some modules evolve more than other
modules do. And there is no point in creating a release of a module
which has not been modified since the last release.

So we leverage OSGi since Sling is running in an OSGi framework: We
assume the package exporters act responsibly and do not introduce
incompatible changes (yes, we (try to) adhere to OSGi's recent semantic
versioning white paper). Thus we try to set the maven dependencies in
our modules to the lowest version possible; put the other way: we don't
upgrade dependencies just because there is a new version available.

Regarding initial versions: Since modules evolve independently, there is
no "prevailing" version. Thus my stance is to start with 1.0 for the
first release.

As for downloading: Of course we provide the latest "full Sling release"
through the down load page. But since we also do module releases, we
just list the latest release of each module on the same download page.
In addition we maintain an OSGi Bundle Repository from where bundles can
directly be installed (e.g. with the Apache Felix Web Console). Apache
Felix does the same, btw. ([3], [4])

Some thoughts on versioning in Sling is also documented in [1] and [2].

Hope this helps.

Regards
Felix

[1] http://sling.apache.org/site/dependency-management.html
[2] http://sling.apache.org/site/version-policy.html
[3] http://sling.apache.org/site/downloads.cgi
[4] http://felix.apache.org/site/downloads.cgi

On 20.08.2010 22:02, Joe Bohn wrote:
> 
> We're in the process of releasing our second set of modules.  This sheds
> new light on the module version and release process discussions we had
> earlier.  It also raises some questions about how we ideally want to
> handle certain scenarios now that we are forced to deal with more than
> one release.
> 
> 1) Should the first release of a new module use the prevailing version
> at the time or do we intend to always start with the logical "1" of a
> first release?  For quiesce we used the prevailing version -
> 0.2-incubating.
> 
> 2) How will we make multiple component versions available in the future
> for download?  If we always release all modules (as we did in our 0.1
> and 0.2 releases) then it's simple - we can create a download page for
> each release and we can create documentation per release.  However, if
> we start to release the modules individually things get a bit more
> complicated.  One possibility is to move from one common download page
> to a download page per module.
> 
> 3) Are there other benefits in keeping the module versions consistent
> and concurrently releasing all modules rather than individual modules
> that we haven't really considered?  I'm thinking about things like
> documentation, test validation, and samples.
> 
> Thinking more about #3 - It seems it might be very difficult to maintain
> our documentation and samples once the module versions begin to diverge.
>  Changes to one module might force us to want to release or update some
> other module, ... such as the case with (and perhaps only with) samples.
>  In fact, samples might be impacted by the release of each module if we
> want to try to keep them as current as possible.  This might result in a
> proliferation of sample releases.  Moreover, the combination of
> modules/versions we use in our sample releases might not demonstrate or
> validate a common set of modules/versions that a user might choose. Yes,
> all valid versions based upon dependencies *should* work fine together
> ... but that assumes nobody makes mistakes.  There is a certain comfort
> (from a user perspective) in knowing that a particular set of modules
> has been tested together in some fashion which can at least be partially
> demonstrated in our samples.
> 
> I understand why we started down the path of individual components and I
> definitely agree that it has value ... I'm just rethinking the decision
> now that we are doing our second release and have to deal with multiple
> versions for the first time.  The second release begins to set the
> precedent for how we deal with some of these things.  The fact that we
> basically released everything again with a consistent version makes me
> wonder if that should be our standard process instead of individual
> component versions.
>