Susanne Oberhauser wrote:
Adrian Schröter
writes: Yes. This is not a big problem (except for storage), but the question is we want to force the user manually to switch repos on updates.
I think in most cases a :Stable and a :Unstable makes more sense.
Let me try to understand what that means.
So I release some software, Bar-o-meter, 1.0.
I've released and tested Bar-o-meter with some other project Foo-foo, Version 1.7, which is what's currently in Foo-foo:Stable.
Now Foo-foo:Stable is updated to 2.0, which breaks APIs. Now I have two bad choices:
* fix my package *right now* and hope nobody has used the broken repos in-between, no matter what I've originally planned doing now.
* copy the base packages in a version that works into my project to be safe from such intrusive changes.
If, however, the release is tagged with some api version, then I've pointed to Foo-foo:Release-1.7 or Foo-foo:Stable-1.7 and I'm safe.
Or maybe Foo-foo:API-1.7?
I'm bringing this up because we've had exactly this problem when rails was updated to 2.0 and that broke packages like our obs packages.
If I remember correctly it was vice versa: from some point in time ruby 2.0 was needed, because ruby rails 2.0 features were use in OBS. Still, there were rails 1.x and rails 2.x pkgs present. But: there is some unhappyness with lots if copied/linked instead of "included" packs like python, ruby, etc. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org