Hi Manuel,
I must say that on a conceptual point of view I like the approach,
keeping one's libraries up to date is the only way to go, however I am
afraid that you are glossing over certain details here:
- you assume that the source code is available, this is a problem if I
am using a 3rd party library for which I only get the binary and THEY
have not migrated yet; how can I use library X (released in 0.9 and
0.10) and library Y (released in 0.11 and 0.12) in the same project ?
Smaller milestones make it a smoother process to upgrade at the
individual level but larger milestones help multiple
people/corporations coordinate.
- you assume that I can actually upgrade; I work at a large software
company, with over 5,000 employees now, and this apply a *large*
source code base. A migration entails an extensive test phase of the
target software/version following by a careful migration of a few
pilot products simply because migrating costs a lot and migrating to a
"flawed" version just to rollback the migration is a cost sink. As a
result though, this creates inertia. Internally we are *always* in the
middle of several migrations (compiler, 3rd party libraries, in-house
middleware, ...) and the larger ones take years. Because of this, once
again we need some coordination: we just cannot afford to migrate
every 6 months (not enough testing time). This means that while it
would not prevent Rust from migrating every 6 months, we would still
be expecting fixes to previous releases for a year or two.
The former means that 6 months might a little *too* fast pace for
industrial projects, the latter means that on top of defining releases
schedule the Rust team will also have to provide a clear plan for
support of "older" versions (how long, what kind of bugs, ...) and the
number of branches impacted may grow quickly: 6 months releases + 2
years support means at least 4 branches, maybe 5 if we count the one
being developed (and 2 years is nothing fancy, as support goes).
-- Matthieu
Ok this makes sense, a release cycle of 2 years + 2 years support for
example might be better once the language is more mature. Until then i
think the suggested approach with the version specified in the source
code and an assisted upgrade path would be helpful to keep the libraries
updated. Also for these larger, less frequent updates such helpers make
the cost of updating smaller.
Thanks for your answer, i was almost sure that it won't be that simple.
Manuel
On Sun, Nov 24, 2013 at 11:49 AM, Manuel <[email protected]
<mailto:[email protected]>> wrote:
I had the following idea to approach language evolution:
Problem:
Languages try to be backward compatible by stabilizing, and only
slowly deprecating old features. This results in a language which
does not evolve. Some different takes about this:
C++: adds new features but does not fix problems, and often does
not remove obsolete features resulting in, well, C++.
Python: Minor versions which add new features, big version jump
from 2 to 3 to make backward incompatible changes. The resulting
incompatibility was a big problem, almost 5 years after the
release of 3.0 (December 3rd, 2008) people are still using 2.x.
Rust seems to follow a similar approach, devs are already defering
features to 2.0 to stabilize.
Other languages simply do not evolve at all and are replaced.
My idea to improve this situation would be to add a version tag in
every main crate, something like "#ver 0.10". For each version
jump the compiler would fix the code automatically, and convert it
to the current language specification. When the library/code is
multiple versions behind the conversions could be applied
successively. This can be done in a lot of cases, see python 2to3
script and even Google did this for go with the tool gofix during
development. With this change not updated libraries would still be
usable in rust. To simplify updating libraries the compiler could,
on demand, print out a report of problematic parts and propose
fixes. Some things can not be fixed with an automatic approach,
for these cases a classic deprecation mechanism or something else
could still be used.
Advantages:
Kind of backward compatibility to old code bases.
Rust can evolve and stay streamlined at the same time.
Compiler does not have to deal with deprecation mechanism, because
you can remove, and change things instantly.
When this would be in place i think it would be best to release
incompatible updates often, but with only a few changes. Every six
months for example.
What do you think about this?
Manuel
_______________________________________________
Rust-dev mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
