Re: [gtkmvc-users] Backwards compatability

[Roberto C. <ca...@fb...>]

Ciao Tobias,

[A-side note for the users: feel free to jump-in if you have 
something to tell the list]

Il 09/26/2010 04:46 PM, Tobias Weber ha scritto:

> the very next thing I would do to SVN is update the 1.2 tests.

Do you have a list of the tests which have to be updated/fixed?

General issue: I would like two have tickets on the tracker to keep 
track of issues we deal with.

> The question is whether to copy them first to check future releases for backwards compatibility.

1.99.x family was thought right do break compatibility with 1.x 
until 2.0 comes. However when easy, we may think to try keeping 
compatibility by exploiting conditional code (depending on some 
option). In general I prefer to keep the code smooth and clean, so 
the criteria for deciding if an incompatible feature is supported 
with conditional code may be:
1. importance/diffusion of the feature
2. was the issue public (i.e. documented)
3. impact on the code base (limited to a few local lines?)
4. impact on the documentation (do we need to keep the old behaviour 
documented? will the old behaviour become deprecated and eventually 
disappear? Or will it remain stable?)

In this specific case, I would keep the old behaviour for 
1.99.0-based applications as it has a very limited impact on the 
code. 1.99.1 will feature the new behaviour. We need to document the 
choice, and make available the options set for controlling the 
framework.

About copying tests: not needed, if we break compatibility, we can 
rely on a svn tag (to be created) for testing old version.

 > Where do we make the cut?
In 1.99.1

 > Is a 1.99.0-comatible release with backported fixes necessary?
No, provided the user can have some control on some 
backward-compatible behaviours via the options.

 > Is GtkBuilder support enough to warrant 2.0?
Mmm, this opens the general question: what 2.0 will bring?
I think we should aim to release 1.99.1 first, as 2.0 requires some 
further discussion.

 > BTW gtkmvc.require would have to raise if it is too *high*
Indeed, until we reach a stable point.

ACTIONS:
1. open issue for the changed behaviour, to keep track of it.
2. add options to the framework (to be analyzed)
3. make the changed behaviour code backward-compatible depending on 
a specific option (iff impact on code is low)
4. document it
5. fix tests

Cheers,
r.

ps.From Oct 4 to Oct 15 I will the chance to dedicate 2 hours a day 
to the project (at last!!). By the 15 I hope we are in good shape to 
think about a possible release date. I am working this week on the 
release plan.