Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We now consider Moment.js to be a legacy project in maintenance mode

momentjs.com

Post reply on HN
Print view View original

131–140 of 266 posts

Re: We now consider Moment.js to be a legacy project in maintenance mode

#131

Post by sokoloff »

tutfbhuf wrote: post #72
bartread wrote: post #67

Earlier quoted context omitted.

> I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing. 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…

> 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 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/

Re: We now consider Moment.js to be a legacy project in maintenance mode

#132

Post by lfischer »

scoopertrooper wrote: post #106
jasonkester wrote: post #92

Earlier quoted context omitted.

You might benefit from flipping this around and asking yourself why you're not able to ship software that remains shipped without intervention. And why you can't even imagine a world where that would be possible. If you spend some time and effort removing whatever obstacles you have in place that are keeping you from being able to do that, you'll have a lot more free time to spend building new things. For what it's w…

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.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#133

Post by [deleted] »

glintik wrote: post #73
dmit wrote: post #52

Please pardon this drive-by assessment of JS calendar libraries by a casual user. moment.js: Mutable. Thank you, next. Luxon: Takes the effort to implement `Interval`, which would be `Range ` in any proper language, but somehow avoids providing separate `Date` and `Time` objects. Day.js: When you kinda like moment.js, but your bundler says it's too fat. date-fns: The finest of pure, curry-able functions over the mine…

"moment.js: Mutable. Thank you, next." Mutable is not bad, buddy. You live in mutable world.

[deleted]

Re: We now consider Moment.js to be a legacy project in maintenance mode

#134

Post by fastball »

nikitaga wrote: post #39
jasonkester wrote: post #5

Good 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…

Is this really what a "done" software is? "Should not be used for new projects" is not "done" imo, it's more like "unfixable" and "obsolete". No prejudice at all against Moment.js or its devs, but this is essentially what they're saying. And the purpose and tone of the article does not seem to be an apology at all, but rather simply setting the expectations for future work so that the maintainers don't have to answer…

Unfixable is very different from obsolete.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#136

Post by 3np »

dmit wrote: post #52

Please pardon this drive-by assessment of JS calendar libraries by a casual user. moment.js: Mutable. Thank you, next. Luxon: Takes the effort to implement `Interval`, which would be `Range ` in any proper language, but somehow avoids providing separate `Date` and `Time` objects. Day.js: When you kinda like moment.js, but your bundler says it's too fat. date-fns: The finest of pure, curry-able functions over the mine…

Anyone has an idea for a solid module that supports representations of sub-millisecond precision (preferrably ns but at least us)?

Re: We now consider Moment.js to be a legacy project in maintenance mode

#137

Post by nathell »

sokoloff wrote: post #131
tutfbhuf wrote: post #72

Earlier 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 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.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#138

Post by iforgotpassword »

randomdata wrote: post #130
bartread wrote: post #67

Earlier quoted context omitted.

> I wish the was a way to fix this attitude. So that project maintainers didn’t need to write two page apologies for finishing their thing. 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…

If an OSS library does what you need, is it not done in any meaningful sense anyway? It makes little difference if the author had hoped to add the kitchen sink, but gave up on it, if you don't need the kitchen sink.

If it does what I need but has a dozen security flaws because the maintainer just doesn't care anymore it makes a difference. You have to dig around to figure this out. On github it's relatively easy to check the issue tracker but still.

One case in point is (was) atftp. Since it's packaged with most distros you might be tempted to assume it's safe to use. But then I encountered a crash on Debian. Tracked down the official project page to sourceforge, found the bug was reported years ago including fix, nothing happened. Found it had several other issues like not checking return values of calls like setuid(). Debian at the time had their own patches for this in sid, since coincidentally someone must have hit the same issue around the time. Checked suse out of curiosity and they also had their own patches which were around for quite some time. Same with gentoo (I think). Obviously all three had different patches for different bugs, because unresponsive upstream. I wish there was a joint effort of distros for such cases instead of duplicating work. Or just drop dead projects with known security issues instead of this half arsed approach.

Sorry, second part is only semi related with the original issue but it's just one more way in which picking the right open source solution for a problem can be difficult because of lacking communication.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#139

Post by hdjdbtbgwjsn »

scoopertrooper wrote: post #125
DougBTX wrote: post #115

Earlier quoted context omitted.

A project can't be more stable than its dependencies and tooling, but that doesn't mean that the only way to be stable is to have no dependencies. Some programming languages make guarantees that old code will build in new versions (eg, ISO C even refuses to introduce new warnings for code that would previously build without warnings), while others will introduce backwards incompatible changes in minor releases. How m…

Library and framework maintainers will eventually stop updating previous major versions. So you manage to tread water just fine till your major version reaches EOL, then you've found yourself in the position of having to change over to a completely new API on a schedule set by the maintainer of the dependency.

It depends on the language. Fortran last broke backwards compatibility with F90. F77 code is still 100% supported. C is similar.

Re: We now consider Moment.js to be a legacy project in maintenance mode

#140

Post by mfru »

jasonkester wrote: post #5

Good 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…

It would seem to be quite easy to do something like:

https://img.shields.io/badge/Maintenance-Legacy-success

or

https://img.shields.io/badge/Maintenance Level-Done-success

and have that as a convention.

Additionally to being easy to implement, it is literally a 3 second task for maintainers to add something like this into their Readme.

Post reply on HN