26 Apr
2011
26 Apr
'11
11:35 a.m.
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. Although I am sure that when you are developing
RPackage, you do want to load the very latest versions of packages :)
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.
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. 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