The symbolic version #development is EXPLICITELY not defined

Hi!

I bumped into the following problem, and I am not sure what I should do.
ConfigurationOfRPackage has two baselines (default and baseline10) and one version (version10), which is declared as stable.
I wanted to add the method #packageName on the class RPackage to make it a bit more polymorphic with PackageInfo. So did I.
However, when I tried to save the project using the browser, I got an error "The symbolic version #development is EXPLICITELY not defined". I bumped into it a number of times already.

What should I do? Manually create version 1.1, declare it as #development ? But this does not save the business because I want the #packageName to be part of the stable version of RPackage.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Alexandre,

The error means that no #development symbolic version has been defined and from your description  that is the case ...  many of the current toolbox methods are written to expect to have a #development symbolic version ... otherwise more information is required in the api call ...

This can be changed by using a different api from the tools ... of course, then we'll have to ask more questions in the ui ...

The add development version command declares the new version as the #development version, but if you add versions manually and don't define a #development symbolic version, then you'll easily run into this problem ...

I suppose in the end the best answer is to have the MetacelloBrowser prompt for a version if no #development version is defined and then call a different api ... how does that sound?

Dale

On Mar 20, 2011, at 7:34 PM, Alexandre Bergel wrote:

> The error means that no #development symbolic version has been defined and from your description  that is the case ...  many of the current toolbox methods are written to expect to have a #development symbolic version ... otherwise more information is required in the api call ...

I find that a bit restrictive. Having a #stable and #development versions works well in the case of Metacello, MetacelloBrowser and many other tools that are being developed. However, in the case of RPackage, this is just a minor fix. The project is small enough to not involve a development version, but just a #stable one.

> I suppose in the end the best answer is to have the MetacelloBrowser prompt for a version if no #development version is defined and then call a different api ... how does that sound?

Which api should be called?

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Mar 21, 2011, at 6:49 PM, Alexandre Bergel wrote:

>> The error means that no #development symbolic version has been defined and from your description  that is the case ...  many of the current toolbox methods are written to expect to have a #development symbolic version ... otherwise more information is required in the api call ...
>
> I find that a bit restrictive. Having a #stable and #development versions works well in the case of Metacello, MetacelloBrowser and many other tools that are being developed. However, in the case of RPackage, this is just a minor fix. The project is small enough to not involve a development version, but just a #stable one.
>
>> I suppose in the end the best answer is to have the MetacelloBrowser prompt for a version if no #development version is defined and then call a different api ... how does that sound?
>
> Which api should be called?

Alexandre,

I think this is about development styles more than specific api calls or error messages ...

I have described in some detail my thinking on the development cycle supported by the Metacello ToolBox:

  http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthed/#walkthrough

I am not saying that this is the only development scenario, but I would prefer an overview (on a similar level of detail) for the development scenario(s) that you are thinking about ....

I think process is important and there _is_ a process involved in creating Metacello versions and just as it is important that the code be tested before release, it is important that versions be tested before release ... there is no difference ... Consequently I disagree with the statement:

  The project is small enough to not involve a development version, but just a #stable one.

If you are making changes to a project that you want to make immediately available, you should open a version for development, make your changes, test the changes, update the version, test the version and release the new version ... no matter how small the change, this is the process that should be followed ....

At this point in time I think we should be focussed on making the primary process work smoothly and as far as I can tell there is more work needed to support the primary process .. once we have a smoothly working UI supporting the primary process I think it makes sense to look at potential shortcuts and alternate schemes.

In reality I don't think we quite agree on the "primary process", I've described what I think the "primary process" is (read the blog post), so I think you need to describe your view of what the "primary process" should be and then we can go from there...

Dale

Hi Dale,

> I think this is about development styles more than specific api calls or error messages ...
>
> I have described in some detail my thinking on the development cycle supported by the Metacello ToolBox:
>
>  http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthed/#walkthrough

I read it several times and I mostly agree with it. The only point where my opinion differ is that I favor multiple numbered versions instead of solely relying on multiple configuration versions.
However, I am flexible. It works well for MetacelloBrowser.

I agree. In this case, I added a method to RPackage.

> At this point in time I think we should be focussed on making the primary process work smoothly and as far as I can tell there is more work needed to support the primary process .. once we have a smoothly working UI supporting the primary process I think it makes sense to look at potential shortcuts and alternate schemes.
>
> In reality I don't think we quite agree on the "primary process", I've described what I think the "primary process" is (read the blog post), so I think you need to describe your view of what the "primary process" should be and then we can go from there...

So in that case, to incorporate an evident fix, I will move the stable caret to 1.1 and create a development 1.2

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Mar 22, 2011, at 6:42 PM, Alexandre Bergel wrote:

I am still not quite sure what the entire scenario is....

  - what is the #stable version?
  - what is the blessing of the #stable version?

From your description it sounds to me like 1.0 is the #stable version, so I'm not sure of the status of 1.1 or 1.2 ...

Dale

>> So in that case, to incorporate an evident fix, I will move the stable caret to 1.1 and create a development 1.2
>
> I am still not quite sure what the entire scenario is....
>
>  - what is the #stable version?
>  - what is the blessing of the #stable version?
>
> From your description it sounds to me like 1.0 is the #stable version, so I'm not sure of the status of 1.1 or 1.2 ...


Sorry for the delay.
Yes, 1.0 is the #stable version. There is only one version declared in ConfigurationOfRPackage. Is the configuration ill defined since there is no #development?
What should I do to add a new method to the RPackage class?
I can add this method in a new version 1.1. Since I want the whole world to use this method, I have to set Version 1.1 as #stable right?
And since there has to be a development version in any configuration, then it has to be 1.2.

Did I get it right?

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Mar 24, 2011, at 3:35 PM, Alexandre Bergel wrote:

The only time to add a #development version is when you are ready to start development for a new version.

> What should I do to add a new method to the RPackage class?
> I can add this method in a new version 1.1. Since I want the whole world to use this method, I have to set Version 1.1 as #stable right?

In your image, you will create development version 1.1, add your method, do a checkpoint dev (saving modified packages, updating version 1.1 and then saving the config), test load your new version (in theory if not in practice)...then release version 1.1 ... this will update the blessing in 1.1 and declare it as #stable and commit the config version.

> And since there has to be a development version in any configuration, then it has to be 1.2.
>
> Did I get it right?

No need to add 1.2 ... only add 1.2 when you are actually ready to do new development. There is no requirement tht a configuration have a #development stable version.

Dale

Ah ok. A configuration may be valid without having a development explicit. That was not the case a few weeks before. Good! I will try

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Mar 27, 2011, at 6:44 PM, Alexandre Bergel wrote:

It's always been that way, however, there was a bug or two in the tool box that lead you to think that a #development version was required....

Dale