>>
>> yes but this is the price to pay if you want a really robust package system.
>> I cannot work on a system where I cannot rollback and check a given version
>> and I cannot work with a system
>> where I can lose half of my work.
>
> Sure. Just do not work with the baseline then.
I dnu what you mean.
> Although I am sure that when you are developing RPackage, you do want to load
> the very latest versions of packages :)
>
>> So sorry but I need to control the version I work with and there is no way I
>> will work on RPackage with default
>> (and yes this is a pain for me too to have to change all the time the
>> configuration but this is the only way).
>
> I do not understand your line of reasoning. You do not have to work with
> default to provide a default.
because people load the default and code based on the default and after a
certain period of time configurations are not updated
and this is the mess.
So now for RPackage there is no default so that people changing it are FORCED
to produce a new configuration with named file.
> If you want to work with a specific version, work with a specific version.
> Default is nothing but a baseline.
Indeed I know that
> You did not remove the other baseline, but you removed default.
Yes I know. I did it on purpose. No way to load latest using default.
> In any case, my message came from the point of view of someone who integrates
> and it is not related to default. I understand your needs but I wanted to
> point out the dangers that come with removing a version.
Yes this was an emergency solution because I succeeded to lose code (which did
not happen to me over the last 10 years in smalltalk).
Now I'm back to the point where
- RPackage tests are better
- Clean SystemAnnouncements
- Green
- I have annotated a lot of issues to fix and verify
- So I will be able to make progress, add more tests
Looks like I control RPackage now.
Stef
