Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove end-of-life 0.12 and 0.10. #32

Closed
wants to merge 1 commit into from
Closed

Remove end-of-life 0.12 and 0.10. #32

wants to merge 1 commit into from

Conversation

paulmillr
Copy link

They are unsupported even in LTS mode since Jan 1: https://github.com/nodejs/LTS

They are unsupported even in LTS mode since Jan 1: https://github.com/nodejs/LTS
@paulmillr
Copy link
Author

cc @williamkapke @dougwilson @hubbed

@williamkapke
Copy link
Owner

Ping @LinusU... thoughts? since it was your push in #12 that put them there! ;)

@dougwilson
Copy link
Collaborator

I mean, unless it's a support burden having them there, I literally just popped up node.green to see what was different between 0.10 and 0.12 the other day :) I guess my argument would be is there any other reason besides unsupported? "can I use" doesn't remove the old browsers that are not supported from their matix.

@dougwilson
Copy link
Collaborator

Sorry, I just realized: if this still keeps the data but simply removes the running of the gathering, that makes sense, since of course there won't be a new release of those versions :)

@paulmillr
Copy link
Author

Actually I wanted to remove it from the table; the reason being: it's hard to scan the table.

If the table only had officially supported node v4, v6 & v7 (v8), it would be simple to glance at the table and judge which features we could use today in node.js apps. What do you think about adding a checkbox or a flag to the site that only enables LTS, officially supported & AWS versions?

@dougwilson
Copy link
Collaborator

What do you think about adding a checkbox or a flag to the site that only enables LTS, officially supported & AWS versions?

I think that's a great idea, similar to how can I use works as well. 👍 from me

@paulmillr
Copy link
Author

For v0.10 / v0.12 — would you prefer to keep those around?

@LinusU
Copy link

LinusU commented Feb 14, 2017

Since I still maintain 0.10 and 0.12 support on a number of packages it's super valuable to me to have this resource. I do agree that it's hard to scan the table though...

I haven't kept myself up to date, but what is the reason for having the groups (7.5.0, 7.4.0, 7.3.0), (6.9.5, 6.9.4, 6.9.3), (5.12.0, 5.11.1, 5.11.0), (4.7.3, 4.7.2)? I haven't been able to find any difference between them, so it seems a bit redundant? Maybe it has something to do with AWS though (update: seems like the supported AWS versions are 6.9.1, 6.2.2, 5.12.0, 4.6.1, 4.4.6, 0.12.17, 0.12.15, 0.10.48, 0.10.46? info from here)

My use case is in almost all cases to see the latest of every major version, for me that is 8.x, 7.x, 6.x, 5.x, 4.x, 0.12.x and 0.10.x. I guess that another use case is to see all active AWS versions. A third use case could be to see only actively supported releases, which I think right now is 7.x, 6.x and 4.x.

Maybe we could have some kind of toggle between these three (or similar) sets? e.g.

  • "All major"
    8.0.0, 7.5.0, 6.9.5, 5.12.0, 4.7.3, 0.12.18, 0.10.48
  • "Active releases"
    8.0.0, 7.5.0, 6.9.5, 4.7.3
  • "AWS supported"
    6.9.1, 6.2.2, 5.12.0, 4.6.1, 4.4.6, 0.12.17, 0.12.15, 0.10.48, 0.10.46

@williamkapke
Copy link
Owner

I mean, unless it's a support burden having them there

Nope- no burden. I actually asked some folks at the conference I'm at and their opinion and that was the same response. So, I'm inclined to leave them there.

but what is the reason for having the groups (7.5.0, 7.4.0, 7.3.0), (6.9.5, 6.9.4, 6.9.3), (5.12.0, 5.11.1, 5.11.0), (4.7.3, 4.7.2)?

... just simplicity in the code. I guess you already dug in the code and saw where it takes the latest 3 versions of each. I don't have a smarter approach to choosing them.. but I need it to be automated whatever it is.

I REALLY want it to group the versions together that do not have any differences. So the headers would need to read like "7.x.x"... then maybe hovering them would enumerate all the individual minor version details. That should reduce it down to each major versions (unless there was a change between a minor that caused a difference that I didn't notice)

This is possible-- but it just requires me finding time... or a volunteer willing to take a stab at it.
It's a pretty major task though.

@LinusU
Copy link

LinusU commented Feb 14, 2017

... just simplicity in the code. I guess you already dug in the code and saw where it takes the latest 3 versions of each. I don't have a smarter approach to choosing them.. but I need it to be automated whatever it is.

Aha, that makes sense. It could pick only the last one though? Or is there any benefit that I'm missing in having the latest three?

I REALLY want it to group the versions together that do not have any differences. So the headers would need to read like "7.x.x"... then maybe hovering them would enumerate all the individual minor version details. That should reduce it down to each major versions (unless there was a change between a minor that caused a difference that I didn't notice)

This! That would make it truly awesome :)

@williamkapke
Copy link
Owner

It is done. The results are now grouped via 20cc76a!

@LinusU
Copy link

LinusU commented Feb 17, 2017

Amazing 🙌 it looks great 😍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants