[BlueBream] BlueBream 1.0b3 released!

[Christophe Combelles]

Le 23/07/2010 19:09, Baiju M a écrit :
> On Fri, Jul 23, 2010 at 9:37 PM, Christophe Combelles<ccomb at free.fr>  wrote:
>> 1.0b3 is broken :( , the versions=versions was missing. It's fixed in the trunk.
>
> Your last release has made it possible to release project template
> without releasing KGS.  I think we need not to synchronize the
> versions of both project template&  KGS.  So, we can make
> a beta 4 release of project template.

if we release the project template but not the KGS, we will have a shift between 
the two versions: template in 1.0b4, KGS in 1.0b3.
In my opinion, we should release both each time : if we release the template 
1.0b4 now, there is no problem releasing the KGS 1.0b4 as well, even if there is 
no change since 1.0b3.  Anyway, in the future the KGS is supposed to change more 
often than the template, and I don't expect releases to happen every week.

Actually I believe we should not make a difference between the KGS and the 
template : we just release "bluebream". It seems simpler to me.

However we should find a way to warn the user of an old version that the 
template has been updated.

Here is an example scenario:
----------------------------
bluebream version:   1.0    1.0.1    1.0.2
KGS modified?         .      yes      no
template modified?    .      no       yes

- A user has installed version 1.0.
- We release bluebream version 1.0.1, with changes *only* in the versions
- The user starts a new project with bluebream 1.0.
=> the project automatically get the new versions of 1.0.1. (done)
- We release bluebream version 1.0.2, with changes *only* in the template
- the user starts a new project again with bluebream 1.0
=> Here, the user should be warned that the latest version contains a new 
template, and that he should upgrade bluebream itself.

How can we implement this behaviour?

A first idea would be to put a comment in the versions.cfg file, detected during 
project creation, holding the latest version containing changes requiring an 
upgrade, and compared against the version used by the user.

So with this scenario, the versions.cfg for 1.0.1 would begin with:

# main version file for BlueBream
# latest version that required an upgrade: 1.0
[buildout]
extends = ...

And the versions.cfg for 1.0.2 would begin with:

# main version file for BlueBream
# latest version that required an upgrade: 1.0.2
[buildout]
extends = ...

I think it's quite easy to implement and to maintain.

Maybe it would also be nice to maintain a migration documentation, telling the 
user what to change in his project once created with 1.0 to be equivalent to 1.0.2.

Christophe

>
> Regards,
> Baiju M
>
>