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 On Sun, Nov 24, 2013 at 11:49 AM, Manuel <ma.adam...@gmail.com> 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 > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
