As a follow-up-thought on the first session in the hack-room today, regarding performance, Stephane Gay ( or was it Morten Christensen ) said that HQ use more time on making the code backwards compatible than on the new code.
That made me think.
I've had a similar talk with Søren Spelling, regarding upgrades in uCommerce where he said, that they on purpose break the code rather than mantaining old code, but keep the changes well documented.
In my opinion, HQ should break the new versions as well, rather than keep using valuable time on maintaining old code and backwards compatebility. Just keep it well documented.
That would force me to use the new and, hopefully, optimized code at once, instead of a "I refactor it later"-thought of mind.
In that way, I would always be forced to optimize my work, if I would like to upgrade the solution.
Maybe it would keep some people not upgrading, due to the extra work in refactoring some code, but I just think we could have better and cleaner solutions if we got rid of all the obsolete code.
What do you think ?
Let's have an online open space discussion.
And as a final note: Thanks alot for the last 3 days. It's been awesome and you all rock.
I think being backwards compatebility is definitly needed. If you make breaking changes in your core it will mean that a lot of package developers will need to update their package. Not every package developer has time for this. This will leave you with a eco system of broken packages that will frustate (new) Umbraco developers.
If we look back at what happened with V5 this was actually the problem. V5 wasn't backwards compatible so no packages could be reused. As not all package developers invested time to convert their packages to V5 a lot of people chose to keep using V4.
I understand sometimes breaking changes are needed to move forward.
So what will needed to make this work.
1. Documentation of breaking changes 2. Package developers should be notified about upcoming breaking changes so they can act on them 3. All project pages on our should automaticly display a notification that the package might not work on the new version. When the package developer has tested or updated his package he can remove the notification. So people will be notified that a package might not work.
Break it or obsolete it ?? Open discussion
I think being backwards compatebility is definitly needed. If you make breaking changes in your core it will mean that a lot of package developers will need to update their package. Not every package developer has time for this. This will leave you with a eco system of broken packages that will frustate (new) Umbraco developers.
If we look back at what happened with V5 this was actually the problem. V5 wasn't backwards compatible so no packages could be reused. As not all package developers invested time to convert their packages to V5 a lot of people chose to keep using V4.
I understand sometimes breaking changes are needed to move forward.
So what will needed to make this work.
1. Documentation of breaking changes
2. Package developers should be notified about upcoming breaking changes so they can act on them
3. All project pages on our should automaticly display a notification that the package might not work on the new version. When the package developer has tested or updated his package he can remove the notification. So people will be notified that a package might not work.
Dave
is working on a reply...