Maybe you could use Versionner for that. If your configuration depends on a #stable version, Versionner can resolve this (check box activated by default) when releasing a new version. Versioner do not have a deep release functionality but it should not be difficult to do if needed; At a time, I created the VSConfigurationGeneratorCommand (in Versionner repo in SH) that follows all the dependencies of a project.

Christophe

Le 7 déc. 2014 à 21:21, Tudor Girba a écrit :

Ok. Let's give this a shot. So, we would need versions in all configurations that point to the concrete number or #stable of the other configurations.

Cheers, Doru

On Sun, Dec 7, 2014 at 2:54 PM, Stephan Eggermont stephan@stack.nl wrote:

...

No. We will create a stable version of each configuration that will be versioned based on the numbering of each configurations.

Last time I was not so happy with the results of using numbered configurations. The release version stopped being usable about a week after the release date. With a symbolic name we can fix critical bugs that stop newcomers from using Moose. Last time we had a development version that didn't work because of significant Pharo3 surgery and a stable version that couldn't be build because of numbered configurations. If possible I would like to avoid that this time.

Stephan

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Le 8 déc. 2014 à 11:09, Tudor Girba a écrit :

Hi,

Indeed, I would want tool support.

The configuration does not depend on #stable. It currently depends on #development, but it should be changed to #stable. Could you handle that?

In Versionner, I assume that the development version is a baseline. If it not, I create a new baseline that becomes the new development version (understand, the current, not yet released version, I work on). Once Versionner has this baseline version, it resolves all kind of symbolic versions to the numbered versions for the release (but still keep the symbolic version in the baseline to use for dev version and next releases).

Also, actually we do not necessarily need a deep release. I extended Metacello with traversal and inspector support possibilities.

ok, so it should be easy. Versionners uses a command pattern so I assume you could call the ReleaseVersion Command on all the configurations without clicking on the Versionner UI. In this case, the only thing is to check that Versionner is happy with the current configuration.

Here is a snippet of code that you can try: | config project | config := ConfigurationOfVersionner. project := MTProject newFromVersion: config project development inConfiguration: config. (VSReleaseDevelopmentVersionCommand target: project devWorkflow for: nil) execute