What about backward compatibility?
Vinicius Assef
This message is more about policy rather than technology, ok?
I am new to web2py and did not develop anything with it, yet.
I just read some docs, watched some slides and video tutorials.
As as newcomer Django user too, I could see some changing behaviour
between versions before 1.0. And who can guarantee me it won't happen
after it? Nobody. I don't see some care about backward compatibility
in Django.
What's web2py commitment with backward compatibility?
If I develop code, this code will turn into "legacy code" in the very
moment it's in production, right?
And some of the worse things on working with customers, is answering
something like: "OK, I can make the change you are asking me. But I'll
have to charge an extra bit due to 'technology update'." My customer
doesn't care about it. And he really doesn't have to. It's my
profession. Not his, right?
Consequently, as a professional, I care about maximizing my own time
investment on learning and using languages and frameworks.
As a mainframe professional for 21 years long, even today I am allowed
to run some programs I developed in my early days on IBM MVS operating
system (I'm talking about 1988!). With no change at all. Such
environment is very stable, despite of language evolution. Yes,
languages change there, too. But it's always backward compatible. It's
about maximizing time and money.
Is there anywhere written about it in web2py documentation or website?
I've not found it, yet.
IMHO it's one of the most important issues when some company chooses
some technology to use.
I am not talking about compatiblity among python versions. I know it's
not a web2py issue, but python's. I'm referring about compatibility
among web2py versions, itself.
--
[ ]s
Vinicius Assef.
mdipierro
> Hi guys.
> This message is more about policy rather than technology, ok?
>
> I am new to web2py and did not develop anything with it, yet.
> I just read some docs, watched some slides and video tutorials.
>
> As as newcomer Django user too, I could see some changing behaviour
> between versions before 1.0. And who can guarantee me it won't happen
> after it? Nobody. I don't see some care about backward compatibility
> in Django.
>
> What's web2py commitment with backward compatibility?
years. We do not accept patches that break it. That is one of the
reason we call web2py an "Enterprise framework". I thought we said
that in the main web page but somehow it disappeared in the last edit.
I will put it back.
viniciusban
On Jul 10, 11:26 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> On Jul 10, 9:12 am, Vinicius Assef <vinicius...@gmail.com> wrote:
>
> > What's web2py commitment with backward compatibility?
>
> We are fully committed to backward compatiliby. We never broke it in 2
> years. We do not accept patches that break it. That is one of the
> reason we call web2py an "Enterprise framework". I thought we said
> that in the main web page but somehow it disappeared in the last edit.
> I will put it back.
I think it is a common shortcomming to companies when they choose to
adopt new technologies.
When a big company takes care of some peace of software, i.e, IBM,
customers know this is on way.
But, actually, this is not web2py's situation, right?
I would put it in web2py homepage and I'd enphasize it. With all
capital letters, colorful, and blinking! (just a joke)
Just saying "enterprise framework", can mean "able to work with large
teams", or "good methods", or "distributed teams", maybe "rapid
development", even "stardards compliant", but not backward compatible.
I'd also say there what you wrote: "We never broke it in 2 years".
It's worth reading. :-)
Backward compatibility is very, very important. Really.
I've worked to big telecom companies, here in Brazil, and this topic
was decisive to make some choices. Frequently, money was not the
problem. Lifetime cicle was. Despite technology or simplicity.
Congratulations.
+1 point to web2py. ;-)
--
[ ]s
Vinicius Assef.
mdipierro
viniciusban
On Jul 10, 12:29 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> OK. check out web2py.com, the second item after the slides.
And so quick. :-)
--
[ ]s
Vinicius Assef.
Yarko Tymciurak
Backward compatibility is (in the big picture) a double-edged sword.
Yes, Massimo is dedicated to backward compatibility, but Python 3 is not. Python not being so wed to backward compatibility has it's benefits (see http://reinout.vanrees.org/weblog/2009/07/01/ep-bruce-eckel.html and http://www.artima.com/weblogs/viewpost.jsp?thread=260578 for example).
Certainly, from web2py's end, backward compatibility is a goal. How many people still run Python 1.6 code, without having migrated it forward (can I see a show of hands?) --- That's my point. When Python 3 moves into the forefront, you may need to make small changes, but this is not the kinds of "rewrites" you are talking about, where your clients don't care. This is "practically backward compatible" in that nothing devastating or earth shaking takes place.
This is probably the same approach to expect here. Backward compatibility is a goal... But you are not encouraged to use T2 (anymore); there are better ways now. Yes, it will still run. And DAL will change, for the better. ... and so on.
The point is to "keep making sense" - consider the client, the developer, AND forward progress, and strike that balance of concerns. (That, after all, is what intentional design is - consider the involved parties, and balancing concerns).
- Yarko
mdipierro
future while still supporting and improving web2py. That is not a
priority right now.
On Jul 10, 1:20 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> The concepts you discuss are... one perspective, one sided (even if
> important).
>
> Backward compatibility is (in the big picture) a double-edged sword.
>
> Yes, Massimo is dedicated to backward compatibility, but Python 3 is not.
> Certainly, from web2py's end, backward compatibility is a goal. How many
> people still run Python 1.6 code, without having migrated it forward (can I
> see a show of hands?) --- That's my point. When Python 3 moves into the
> forefront, you may need to make small changes, but this is not the kinds of
> "rewrites" you are talking about, where your clients don't care. This is
> "practically backward compatible" in that nothing devastating or earth
> shaking takes place.
>
> This is probably the same approach to expect here. Backward compatibility
> is a goal... But you are not encouraged to use T2 (anymore); there are
> better ways now. Yes, it will still run. And DAL will change, for the
> better. ... and so on.
>
> The point is to "keep making sense" - consider the client, the developer,
> AND forward progress, and strike that balance of concerns. (That, after
> all, is what intentional design is - consider the involved parties, and
> balancing concerns).
>
> - Yarko
>