I tend to agree with Nico that it seems a bit silly to artificially
prolong support for what you might call a bug (or at least very
surprising behavour). allthough i generally think backwards
compatibility is important, i also think it is important to be able to
say goody to mistakes from the past. the next release is addressing a
lot of features that were perhaps a bit underdeveloped in the past, and
i guess there will be some issues upgrading to this version (with regard
to new datatypes - fieldtypes). So why not take all the pain at once?
Otherwise we will have something like: here is release 1.9. It dous not
dramatically change existing systems, but oh, expect some upgrading
effort becouse now we are going to drop support for non-existing fields.
Perhaps it's best to take the pain straight away?
I might add that it is a bit funny though that this release, that was
supposed to be a bugfix and code clean release, has more new features
than any i can remember in the past. Way to go! :-)
Ernst
Michiel Meeuwissen wrote:
On 15 Oct 2005, at 11:40, Nico Klasens wrote:
Reading this thread I wonder what upgrading/moving to 1.8 means?
Does it mean, throw in the jars and it should work? Or does it mean
that the application uses the preferred syntax/settings of 1.8?
The former case does not make any sense to me. Upgrading because you
want the same functionality the old one has?
<snip>
- ....
For me it is the latter and that means that it will take at least a
week to upgrade and test the application.
I would normally also try to update a site completely, but this may
not be feasible, if the site is very big (vpro or so), and you want
to use new features on only parts of it. One may also be interested
in dropping in the jars to profit from performance and bug fixes.
So, principally it would be nice if dropping in the new jars would
work. If custom extensions need some tinkering, e.g. because they
used deprecated code which was now removed, then I find that
acceptable because at least that is found compile-time (in other
words, I think it is required at least that you recompile your
extensions).
But still I can garantuee that even that is not enough, and that it
would certainly be wise to some tests (also on the front-end), after
dropping in the new jars. I'm not sure what kind of problems will
arise. I've tried this several times in the past months with several
of my own sites, and sometime I made a change to make the jars more
backwards compatible (from the idea that if I run into something,
someone else may as well). So I think MMBase 1.8 will be sufficiently
backwards compatible for me. But your mileage may vary, and I suppose
that the actual backwards compatibility depends largely on ones
codeing style, so I beg everybody to test before the release, also
for backwards compatibility issues, or don't whine afterwards. I
understand from your mail that _you_ won't whine, because you take it
for granted that such an update will require some work, and you know
what was changed. But I just fear that not everybody is realising
this....
Michiel
--
mihxil'
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
