Release process for Moose components and subcomponents

Hi

I really think that
     - everybody should use versionner :) because now that I use it it
is really nice.
     - we should use baseline for development during development
     - we should use stable or versionned for external packages such as XML.
     - with versionner we can release at the end of every week or two in
probably some clicks.
     (I can ask christophe for some improvements).

So can we agree on that because we can make sure that we have the
advantges that now
and have at the end of every week a versionned released?

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Stef,

is there any tutorial on how to use versioner? Because all metacello magic is to complicated for me. In ruby gems it’s simple: you gust specify a project name and a version you want to use. And here we need to deal with all the baselines, symbolic versions and so on.

Uko

On 30 Jun 2014, at 10:32, stepharo <[hidden email]> wrote:


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

It is two clicks.
Christophe did a video you should check it in the Pharo mailing

In a nutshell
     in devlopment you commit normally your packages.
       -  to load you click on development and load the latest ones.

     in dev if you change the baseline, (you change it)
        - you click on dev
        - save (to development) + commit

     to release
     you click on development
         - release (-> this creates a new version)
         - commit

:)

done

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I really think that I was discussing with christophe and
     - for external projects that we do not control we could also fork
and maintain our own configuration.
     - for people working on alpha pharo versions (we should think about
a ConfigurationOfPharo that PharoTeam should do.)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Yes. That is pretty much the model we want for Moose.

I already started to work with Versionner. It is a bit complicated,

why?

but I am happy it exists. We can iterate from this point on.

This is the point.

I did not see how I can release deep configurations, though.

Indeed christophe can improve that part.
For now we will have to click manually on the top levels configurations and release them.

Stef

Doru

On Mon, Jun 30, 2014 at 10:32 AM, stepharo <[hidden email]> wrote:

Hi

I really think that
    - everybody should use versionner :) because now that I use it it is really nice.
    - we should use baseline for development during development
    - we should use stable or versionned for external packages such as XML.
    - with versionner we can release at the end of every week or two in probably some clicks.
    (I can ask christophe for some improvements).

So can we agree on that because we can make sure that we have the advantges that now
and have at the end of every week a versionned released?

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stef,

Just to be sure I understand our goal properly:
We want to create a stable version with versioner at the end of the week. A stable version is a version that only gets approved changes (where we can have discussion about when a change gets approved for moose …).

If we want a snapshot (no bug fixes allowed, 100% reproducible), we should not pollute the configuration with it. And then we need to have a complete list with all packages. That means: that we need a snapshot of Pharo too.

I am currently taking a look at versioner and trying to determine if this workflow would be acceptable. I tried it on Moose and and Glamour. And this is the problems I have:
        - The comment on the release button says: create a new version and a new baseline. Pressing the button does not create a new baseline (this is good), so please fix the comment here.
        - Pressing the button suggests it resolves all symbolic dependencies to actual versions. I want more control here. In Moose the correct version for Grease is currently #’release1.1’. For Magritte3 this should be #’release3.1’.
        - Dialog is way too small: I cannot see the version number I am creating.
        - The suggested version number is incorrect. I.e. for moose it should be 5.0 or 5.0.0. For glamour it should be 2.9 or 2.9.0.
        - Looking at the version:
                > when you want to create a stable version, starting at a development version, it should also "upgrade the references" to used projects to stable. Either by using the latest stable, or by creating a new stable version is the current version is newer. This means that each time it encounters a project that is “dirty” in the sense I described above, I get a dialog asking me if I want to create new version and what version number this should be.
                > I do not get the possibility of adding a good description.
                > In glamour I get 2 common blocks.
                        - both common blocks define author, timestamp, blessing and description.

These problems should be fixed before we can do this. And of course, we should check for all projects if the result is the desired result.

Diego

On 30 Jun 2014, at 10:32, stepharo <[hidden email]> wrote:


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Stef,

Why isn’t this process first tested in Pharo. To avoid problems in the future I would like to suggest that for the coming month we create a version in the ConfigurationOfPharo each build of Pharo. As you say: this is just one click and everybody should use it …

I fear that the size of the configuration might give problems, and this is a very good way to discover problems with the suggested process.

Diego

On 30 Jun 2014, at 10:32, stepharo <[hidden email]> wrote:


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Steph wrote
>I was discussing with christophe and
>     - for external projects that we do not control we could also fork
>and maintain our own configuration.

That is madness for maintained projects. You might need a snapshot, but don't want to
do the work to maintain a configuration.

Stephan


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Versioner cannot currently be used to make the switch from Pharo 3 to Pharo 4.
It also cannot be used to maintain Moose versions for both.
If you want to be able to maintain versions delivered to customers,
you'll need the platform support and need to be able to DRY configurations.

The delivered configuration is unlikely to load in a current Pharo image,
so it needs a dependency on a ConfigurationOfPharo version

Stephan




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I'm really busy today but I could try to do a video.
Tell me if the description I sent is ok for you.
Would be good to have a one page tutorial in a cool blog :)

Stef

On 30/6/14 10:56, Yuriy Tymchuk wrote:
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 30/6/14 11:32, Diego Lont wrote:
> Stef,
>
> Just to be sure I understand our goal properly:
> We want to create a stable version with versioner at the end of the week. A stable version is a version that only gets approved changes (where we can have discussion about when a change gets approved for moose …).
There are two goals (orthogonal in fact)

     - how can we reproduce (reload) an exact version of the same
packages regularly (for example every two weeks)
     without pain? While supporting the load latest in dev and freeze model.

     - how can we provide a modular infrastructure for everybody
building on top of the moose infrastructure:
     MooseIDE + synectique tools should reuse extend the same
infrastructure (called mooseEngines by Doru)?


>
> If we want a snapshot (no bug fixes allowed, 100% reproducible), we should not pollute the configuration with it. And then we need to have a complete list with all packages. That means: that we need a snapshot of Pharo too.
     Yes but let us start to clean in front of our door and after we
kick the ass of these pharo people :)

>
> I am currently taking a look at versioner and trying to determine if this workflow would be acceptable. I tried it on Moose and and Glamour. And this is the problems I have:
> - The comment on the release button says: create a new version and a new baseline. Pressing the button does not create a new baseline (this is good), so please fix the comment here.
     Easy
> - Pressing the button suggests it resolves all symbolic dependencies to actual versions. I want more control here. In Moose the correct version for Grease is currently #’release1.1’. For Magritte3 this should be #’release3.1’.
     Yes we were talking about it with Christophe.
> - Dialog is way too small: I cannot see the version number I am creating.
> - The suggested version number is incorrect. I.e. for moose it should be 5.0 or 5.0.0. For glamour it should be 2.9 or 2.9.0.
        For me if all the rest work this is ok :)

        - Looking at the version:
                > when you want to create a stable version, starting at a development version, it should also "upgrade the references" to used projects to stable. Either by using the latest stable, or by creating a new stable version is the current version is newer. This means that each time it encounters a project that is “dirty” in the sense I described above, I get a dialog asking me if I want to create new version and what version number this should be.
                         > I do not get the possibility of adding a good description.
                > In glamour I get 2 common blocks.
                        - both common blocks define author, timestamp, blessing and description.

                Problably

  These problems should be fixed before we can do this.

We should start and give feedback as you are doing it. Tx. I think that people like clients so we should use versionner
and contact christophe :)


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Hi Stef,
>
> Why isn’t this process first tested in Pharo.
Because Pharo is another beast. I would love to but Pharo is huge and we
still have plenty to problems with dependencies.
In Moose I cleaned a lot of configurations when I want to reload
configurations with Snapshotcello.


> To avoid problems in the future I would like to suggest that for the coming month we create a version in the ConfigurationOfPharo each build of Pharo. As you say: this is just one click and everybody should use it …
>
> I fear that the size of the configuration might give problems, and this is a very good way to discover problems with the suggested process.
:)


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I will let a chance to christophe to reply.
For now if we succeed to freeze part of moose on release and for other part use baseline we will already be better
than now (I hope) and we can iterate with christophe.

Stef

Yes, I saw this. But, I did not see what happens when you have nested configurations. How do you control which version of the nested config to point to in your new version?

Cheers,

Doru

On Mon, Jun 30, 2014 at 11:27 AM, stepharo <[hidden email]> wrote:

It is two clicks.
Christophe did a video you should check it in the Pharo mailing

In a nutshell
    in devlopment you commit normally your packages.
      -  to load you click on development and load the latest ones.

    in dev if you change the baseline, (you change it)
       - you click on dev
       - save (to development) + commit

    to release
    you click on development
        - release (-> this creates a new version)
        - commit

:)

done

Uko

On 30 Jun 2014, at 10:32, stepharo <[hidden email]> wrote:

Hi

I really think that
    - everybody should use versionner :) because now that I use it it is really nice.
    - we should use baseline for development during development
    - we should use stable or versionned for external packages such as XML.
    - with versionner we can release at the end of every week or two in probably some clicks.
    (I can ask christophe for some improvements).

So can we agree on that because we can make sure that we have the advantges that now
and have at the end of every week a versionned released?

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Uko2 wrote

is there any tutorial on how to use versioner?

https://www.youtube.com/watch?v=S5Dbmmln8tA

Tudor Girba-2 wrote

I already started to work with Versionner. It is a bit complicated, but I
am happy it exists. We can iterate from this point on.

The goal of Versionner is to made configurations easy. So, I'm very interested to know what was complicated for you to improve that.

Tudor Girba-2 wrote

I did not see how I can release deep configurations, though.

For now, it is not possible because Versionner was thinked to manage one project at a time. Stephane explained me a bit how Moose configs management works and yes, it could be useful for you to be able to do some kind of "deep release". I will check how to do that.

DiegoLont wrote

Just to be sure I understand our goal properly:
We want to create a stable version with versioner at the end of the week. A stable version is a version that only gets approved changes (where we can have discussion about when a change gets approved for moose …).

If we want a snapshot (no bug fixes allowed, 100% reproducible), we should not pollute the configuration with it. And then we need to have a complete list with all packages. That means: that we need a snapshot of Pharo too.

Yes, we should really take care that released (numbered versions with exact packages leading to reproducible loadings) are not snapshots. A release should correspond to something else that just the version of the week XX. A release should provides a list of changes / features accepted by the community, thus forming a coherent set of packages.
I'm also against a bloated configuration with released versions corresponding to nothing.
The best is to be able to do a release easily, only when needed.

DiegoLont wrote

I am currently taking a look at versioner and trying to determine if this workflow would be acceptable. I tried it on Moose and and Glamour. And this is the problems I have:
        - The comment on the release button says: create a new version and a new baseline. Pressing the button does not create a new baseline (this is good), so please fix the comment here.

right, thanks. In a first time, at each time a structural change was made to the configuration, a new baseline was created. It is not true anymore. I will update the comment.

DiegoLont wrote

        - Pressing the button suggests it resolves all symbolic dependencies to actual versions.
I want more control here. In Moose the correct version for Grease is currently #’release1.1’. For Magritte3 this should be #’release3.1’.

You can also set the specific version directly in the development version but, if I understand well, you would like to specify any version at the release time?

DiegoLont wrote

        - Dialog is way too small: I cannot see the version number I am creating.

Spec problem. I don't know how to fix this pb.

DiegoLont wrote

        - The suggested version number is incorrect. I.e. for moose it should be 5.0 or 5.0.0. For glamour it should be 2.9 or 2.9.0.

What was suggested? Versionner relies on the max version detected by Metacello for that.

DiegoLont wrote

        - Looking at the version:
                > when you want to create a stable version, starting at a development version, it should also "upgrade the references" to used projects to stable. Either by using the latest stable, or by creating a new stable version is the current version is newer. This means that each time it encounters a project that is “dirty” in the sense I described above, I get a dialog asking me if I want to create new version and what version number this should be.

It looks like it is the core feature missing for Moose peple: some kind of deep release.
Here, I would like suggestions on how to do that. For such a big configuration, you may end with dozens of dialog boxes (for each projec) and a huge process.

DiegoLont wrote

                > I do not get the possibility of adding a good description.

I should ask in the release panel. The description label displayed is not good to do that.

DiegoLont wrote

                > In glamour I get 2 common blocks.
                        - both common blocks define author, timestamp, blessing and description.

Strange, I should try to reproduce.

DiegoLont wrote

These problems should be fixed before we can do this. And of course, we should check for all projects if the result is the desired result.

Don't hesitate to open bugs/feature requests and/or contribute.

Regards,
Christophe.

Just to add my 2 cents: you can specify an initial window size for a Spec window by defining an extent method at instance side. For example:

extent
        ^1000@600

That should be big enough :-)

On Jun 30, 2014, at 8:32 AM, demarey <[hidden email]> wrote:

> DiegoLont wrote
>> - Dialog is way too small: I cannot see the version number I am creating.
>
> Spec problem. I don't know how to fix this pb.



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev