Adrian Schröter
* build old and new ones in Stable project. Since the api breaks, you would anyway need to be able to install the old version beside the new one.
Hmmm... like this, with explicit API version requires and provides in the packages and duplicate packages in the project? :Good-weather/:Bar-o-meter/bar-o-meter.spec Version: 1.0 Requires: Foo-foo-api = 1.7 :Cooltech/:Foo-foo/Foo-foo-1.7/foo-foo.spec Version: 1.7.3 Provides Foo-foo-api = 1.7 :Cooltech/:Foo-foo/Foo-foo-2.0/foo-foo.spec Version: 2.0.3 Provides Foo-foo-api = 2.0 This could work with the new 11.0 solver, as it takes 'the best' instead of the newest package. Or will this result in annoying error messages: Can't update package foo-foo, that would break dependencies. (*) ignore update of package foo-foo ( ) remove package bar-o-meter 'Freezing' package foo-foo is _not_ an option because it may be very reasonable to provide an update to Foo-foo-1.7, Version: 1.7.4, and _that_ should be installed right away.
When you add numbers, you enforce all users and packagers to switch manually.
For the packagers this would be ok, because as the API breaks the packages need to be touched anyway to get them working on the new API. For the users, we need an update path from anumber of connected repos to a number of corresponing repos anway, because we need to migrate base products and add-on products (and add-ons hereof): GA --> SP1 add-on-to-GA --> add-on-to-SP1 (or possibly SP1 obsoletes this add-on) S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org