We now consider Moment.js to be a legacy project in maintenance mode
141–150 of 266 posts
Re: We now consider Moment.js to be a legacy project in maintenance mode
#142Good for them. Open Source seems to have an irrational fear of done . Done is good. Done should be the goal. But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned , dead . To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” I wish the was a way to fix this attitude. So that project maintainers didn’t need to write tw…
"Done" as a goal would maybe mean "mature", "polished", "complete".
But in this case they also say they don't actually recommend Moment.js for new new projects, generally. "we would like to discourage Moment from being used in new projects going forward." In this case "done" also basically means "obsolete", "newer better alternatives exist".
That doesn't seem to be the kind of "finished" that you are talking about, or that would be a goal of developers. Or is it?
Examples of open source projects which are very popular, mature, not obsolete, still recommended by their maintainers for new projects -- but also "done" -- might be closer to what you are trying to compliment. They are definitely few and far between.
Re: We now consider Moment.js to be a legacy project in maintenance mode
#143Earlier quoted context omitted.
So your projects have no dependencies? You just write everything from scratch? Your code is perfect the first time you write it? I'm utterly confused by this comment.
Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve and I find it reasonable to write such code with no external dependencies except the Java standard library, which almost never breaks backward compatibility.
Alright, fair, but then again what if you're building something more complex, where CSV-parsing is just 1% of what it does? Do you implement every single non-standard library functionality you need?
Re: We now consider Moment.js to be a legacy project in maintenance mode
#144Earlier quoted context omitted.
> One of the problems is that GitHub is full of OSS libraries where the last commit was three years or more ago and you have no idea (without forensically analysing commits, issues, etc.) whether it's because the project is done or because the maintainer(s) lost interest, had other priorities, etc. I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does…
>I don't think there's any at least medium sized project that is considered to be done but not abandoned/legacy and does not receive any commits. As another commenter mentioned, this can be pretty common in math libs. Here's an example: https://github.com/fommil/netlib-java This project BLAS/LAPACK/ARPACK bindings for JVM languages. The repository is marked as archived and the owner explicitly states that the project…
The README.md contains install instructions for Debian and Ubuntu, these tend to outdate (not work) quite fast with newer versions of the distributions. Also if any of the low-level libraries BLAS, LAPACK or ARPACK updates, then the wrapper might not continue to work with newer versions or is stuck on a legacy version including bugs and security issues 4 ever.
> This project is still heavily used, there are still multiple libraries that use those bindings.
Heavily used does not imply that a dependency is not abandoned.
Re: We now consider Moment.js to be a legacy project in maintenance mode
#145Earlier quoted context omitted.
So your projects have no dependencies? You just write everything from scratch? Your code is perfect the first time you write it? I'm utterly confused by this comment.
Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve and I find it reasonable to write such code with no external dependencies except the Java standard library, which almost never breaks backward compatibility.
CSV is a very bad example. Yes, it is easy to throw together a simple regex to parse simple RFC4180 CSV strings, but Excel is its own black box with a huge number of hacks.
For example, en-US excel will automagically parse TRUE and "TRUE" to be the logical value TRUE. The way to get Excel to see a literal string TRUE is to make a formula ="TRUE". Many CSV writers implement this hack specifically assuming files will be read back in Excel. So now your parser, if you're trying to process data like Excel, has to do the same.
So then you discover that this is actually localized! If you set your UI language to French (France), Excel will treat VRAI and FAUX as booleans while TRUE and FALSE are treated as literal strings.
What you thought was a simple CSV parser now has to handle localization as well. So that CSV parser library can roll its own dodgy localization support, use a tried and true solution, or just choose not to support the feature. Each choice has its own drawbacks
Re: We now consider Moment.js to be a legacy project in maintenance mode
#146> used in millions of projects Are there really millions of not-toy javascript projects out there?
Without a doubt. Remember there are lots of not-toy software projects that aren't publicly published.
Re: We now consider Moment.js to be a legacy project in maintenance mode
#147Earlier quoted context omitted.
So your projects have no dependencies? You just write everything from scratch? Your code is perfect the first time you write it? I'm utterly confused by this comment.
Imagine a CSV parser written in Java. I can imagine quite well that it would rarely need updates, as CSV does not evolve and I find it reasonable to write such code with no external dependencies except the Java standard library, which almost never breaks backward compatibility.
What if you're working in a domain which does evolve? For example, every domain.
Re: We now consider Moment.js to be a legacy project in maintenance mode
#148Good for them. Open Source seems to have an irrational fear of done . Done is good. Done should be the goal. But it’s not. Because if you’re not adding new features and pushing code changes every day, your project is abandoned , dead . To quote another thread from two minutes ago: “I’m quite sad to see the end of Moment.js” I wish the was a way to fix this attitude. So that project maintainers didn’t need to write tw…
"Done" as a goal would maybe mean "mature", "polished", "complete". But in this case they also say they don't actually recommend Moment.js for new new projects, generally. "we would like to discourage Moment from being used in new projects going forward." In this case "done" also basically means "obsolete", "newer better alternatives exist". That doesn't seem to be the kind of "finished" that you are talking about, o…
They seem to not recommend it solely because it doesn't support immutability or tree shaking.
Re: We now consider Moment.js to be a legacy project in maintenance mode
#149Earlier quoted context omitted.
I was hoping to use Tex as the counter example here, because it’s a large system that’s remarkably stable. However, it’s not actually a counter example as there are small commits periodically. So I’ll post here admitting to be wrong in my instinct. https://www.tug.org/svn/texlive/
That's TeX Live, a distribution of TeX. TeX: The Program has had its most recent release in January 2014.
Thanks. I was noodling around on my phone trying to find it and landed there incorrectly.
Re: We now consider Moment.js to be a legacy project in maintenance mode
#150Earlier quoted context omitted.
"Done" as a goal would maybe mean "mature", "polished", "complete". But in this case they also say they don't actually recommend Moment.js for new new projects, generally. "we would like to discourage Moment from being used in new projects going forward." In this case "done" also basically means "obsolete", "newer better alternatives exist". That doesn't seem to be the kind of "finished" that you are talking about, o…
They seem to not recommend it solely because it doesn't support immutability or tree shaking.
Another important reason mentioned is that it includes heavy-weight internationalization locale files that are not needed in recent browsers -- "for the size alone." I don't know at what point the adjective "solely" stops being appropriate.
Those who have been developing it for years and are most familiar with it, and the alternatives, discourage it's use in new projects, although also outline the exceptions that in their opinion make it reasonable to keep using it. You are going to take a stand to disagree with them, based on superior understanding?