package/nodejs: Add version 5.2.0

v5.2.0 is the current Stable release. See
https://nodejs.org/en/blog/release/v5.2.0 for details on the release.

Signed-off-by Martin Bark <[email protected]>

Martin,

Quoted 4 lines · Martin Bark

v5.2.0 is the current Stable release. See
https://nodejs.org/en/blog/release/v5.2.0 for details on the release.

Signed-off-by Martin Bark <[email protected]>

So, we already have 0.10.x, 0.12.x, 4.2.x and now 5.2.x ?

Is it possible to get rid of some older versions, rather than keeping all of them available ?

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

I'm not sure the answer to that. What i can say is that all four are getting maintained. Also, according to https://github.com/nodejs/LTS
node.js 0.10.x will be maintained all the way until October 2016.

I see two logical approaches for buildroot:

1) Support all four in buildroot because node.js support all four
2) Only Support the 4.x and 5.x because they are the current LTS and Stable releases (i.e. the ones on the front page of
https://nodejs.org)

Personally I'd vote for 2) because it simplifies things.

What are your thoughts?

Quoted 11 lines

I'm not sure the answer to that. What i can say is that all four are getting maintained. Also, according to https://github.com/nodejs/LTS
node.js 0.10.x will be maintained all the way until October 2016.

I see two logical approaches for buildroot:

1) Support all four in buildroot because node.js support all four
2) Only Support the 4.x and 5.x because they are the current LTS and Stable releases (i.e. the ones on the front page of
https://nodejs.org)

Quoted 3 lines

Personally I'd vote for 2) because it simplifies things.

What are your thoughts?

I'm fine with option (2) as well, but do we have other NodeJS users that would like to see 0.10.x and 0.12.x being kept?

Is there any issue for users of 0.10.x/0.12.x to migrate to 4.2 or 5.2 ?

Thomas, All,

On 2015-12-14 21:43 +0100, Thomas Petazzoni spake thusly:

Quoted 12 lines · Martin Bark

Quoted 11 lines

I'm not sure the answer to that. What i can say is that all four are getting maintained. Also, according to https://github.com/nodejs/LTS
node.js 0.10.x will be maintained all the way until October 2016.

I see two logical approaches for buildroot:

1) Support all four in buildroot because node.js support all four
2) Only Support the 4.x and 5.x because they are the current LTS and Stable releases (i.e. the ones on the front page of
https://nodejs.org)

Quoted 8 lines

Quoted 3 lines

Personally I'd vote for 2) because it simplifies things.

What are your thoughts?

I'm fine with option (2) as well, but do we have other NodeJS users that would like to see 0.10.x and 0.12.x being kept?

Is there any issue for users of 0.10.x/0.12.x to migrate to 4.2 or 5.2 ?

We do have the various version of nodejs, because:

- 4.2.x needs gcc >= 4.8 and armv6+
- 0.12.x needs armv6+
- 0.10.x has not requirement

Going back in our history:

- we had nodejs-0.10
- someone proposed to bump to 0.12
- someone else wanted to keep 0.10 around because of armv6+ requirement
- so we added 0.12, and kept 0.10
- the story repeated itself with 4.2.x

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 20 lines

On 2015-12-14 21:43 +0100, Thomas Petazzoni spake thusly:

Quoted 19 lines · Martin Bark

Quoted 6 lines

I'm not sure the answer to that. What i can say is that all four are getting maintained. Also, according to https://github.com/nodejs/LTS
node.js 0.10.x will be maintained all the way until October 2016.

I see two logical approaches for buildroot:

Quoted 8 lines

1) Support all four in buildroot because node.js support all four
2) Only Support the 4.x and 5.x because they are the current LTS and Stable releases (i.e. the ones on the front page of
https://nodejs.org)

Personally I'd vote for 2) because it simplifies things.

What are your thoughts?

I'm fine with option (2) as well, but do we have other NodeJS users that would like to see 0.10.x and 0.12.x being kept?

Quoted 7 lines

Quoted 1 line

Is there any issue for users of 0.10.x/0.12.x to migrate to 4.2 or 5.2 ?

We do have the various version of nodejs, because:

- 4.2.x needs gcc >= 4.8 and armv6+
- 0.12.x needs armv6+
- 0.10.x has not requirement

Quoted 7 lines

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

Quoted 6 lines

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

Yes I like option 3) too. This would clarify the situation so that buildroot supports the latest version of node.js only, except 0.10.x which is kept purely for armv5 support. Then in the buildroot 2016.11 release 0.10.x can be dropped too as it will no longer be maintained.

Thomas, All,

On 2015-12-14 21:43 +0100, Thomas Petazzoni spake thusly:

Quoted 17 lines · Martin Bark

Quoted 16 lines

I'm not sure the answer to that.??What i can say is that all four are
getting maintained.??Also, according to https://github.com/nodejs
/LTS
node.js 0.10.x will be maintained all the way until October 2016.

I see two logical approaches for buildroot:

1) Support all four in buildroot because node.js support all four
2) Only Support the 4.x and 5.x because they are the current LTS and
Stable releases (i.e. the ones on the front page of
https://nodejs.org)

Personally I'd vote for 2) because it simplifies things.

Quoted 7 lines

Quoted 1 line

What are your thoughts?

I'm fine with option (2) as well, but do we have other NodeJS users that would like to see 0.10.x and 0.12.x being kept?

Is there any issue for users of 0.10.x/0.12.x to migrate to 4.2 or 5.2 ?

We do have the various version of nodejs, because:

? - 4.2.x needs gcc >= 4.8 and armv6+
? - 0.12.x needs armv6+
? - 0.10.x has not requirement

Going back in our history:

? - we had nodejs-0.10
? - someone proposed to bump to 0.12
? - someone else wanted to keep 0.10 around because of armv6+ ????requirement
? - so we added 0.12, and kept 0.10
? - the story repeated itself with 4.2.x

So, I think we have a few options here:

?1) keep all the three existing versions, add 5.2
?2) keep 0.10 and 0.12, replace 4.2 with 5.2
?3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
?4) dith 0.10 and 0.12, replace 4.2 with 5.2

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

Quoted 50 lines · Yann E. MORIN

Thomas, All,

On 2015-12-14 21:43 +0100, Thomas Petazzoni spake thusly:

Quoted 17 lines · Martin Bark

Quoted 16 lines

I'm not sure the answer to that. What i can say is that all four are
getting maintained. Also, according to https://github.com/nodejs
/LTS
node.js 0.10.x will be maintained all the way until October 2016.

I see two logical approaches for buildroot:

1) Support all four in buildroot because node.js support all four
2) Only Support the 4.x and 5.x because they are the current LTS and
Stable releases (i.e. the ones on the front page of
https://nodejs.org)

Personally I'd vote for 2) because it simplifies things.

Quoted 7 lines

Quoted 1 line

What are your thoughts?

I'm fine with option (2) as well, but do we have other NodeJS users that would like to see 0.10.x and 0.12.x being kept?

Is there any issue for users of 0.10.x/0.12.x to migrate to 4.2 or 5.2 ?

We do have the various version of nodejs, because:

- 4.2.x needs gcc >= 4.8 and armv6+
- 0.12.x needs armv6+
- 0.10.x has not requirement

Going back in our history:

- we had nodejs-0.10
- someone proposed to bump to 0.12
- someone else wanted to keep 0.10 around because of armv6+ requirement
- so we added 0.12, and kept 0.10
- the story repeated itself with 4.2.x

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

Quoted 7 lines

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

As 4.x is a LTS release I would not drop it for the 5.x release.

I would keep all the three version we have - they are all still maintained and v0.12 and v4 are both even LTS releases.

New versions are often not compatible with older versions of Node.js - it's similiar to Lua.

So I would lean toward 1.

Quoted 23 lines

Quoted 7 lines

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

Quoted 7 lines

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

As 4.x is a LTS release I would not drop it for the 5.x release.

I would keep all the three version we have - they are all still maintained and v0.12 and v4 are both even LTS releases.

New versions are often not compatible with older versions of Node.js - it's similiar to Lua.

Quoted 1 line

So I would lean toward 1.

I agree with you. Dropping a LTS version doesn't look good to me. We could do it when it's not maintained anymore. Right now I vote for keeping the three versions we already have plus adding the 5.2.0 because is the new stable: option 1.

Quoted 23 lines

Quoted 23 lines

Quoted 7 lines

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

Quoted 7 lines

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

As 4.x is a LTS release I would not drop it for the 5.x release.

I would keep all the three version we have - they are all still maintained and v0.12 and v4 are both even LTS releases.

New versions are often not compatible with older versions of Node.js - it's similiar to Lua.

Quoted 6 lines

Quoted 1 line

So I would lean toward 1.

I agree with you. Dropping a LTS version doesn't look good to me. We could do it when it's not maintained anymore. Right now I vote for keeping the three versions we already have plus adding the 5.2.0 because is the new stable: option 1.

I am personally not very happy with option (1). Keeping gazillions of versions means that we have potentially to test all those options. And the random testing done by the autobuilders does not work to randomize "choice" options, i.e we will never test the non-default versions.

What is the motivation for keeping all those versions around? While I can understand that keeping 0.10.x around to have a fallback solution for ARMv5 platform is desired, I don't understand why we would keep 0.12.x and 4.2.x.

The fact that 0.12.x and 4.2.x are still maintained upstream as LTS versions is completely irrelevant. There are other projects that may maintain older branches as LTS, and still we don't support all the possible maintained versions.

Are there incompatibilities between 0.12.x, 4.2.x and 5.2.x that prevent a user from easily upgrading?

Thomas, All,

On 2015-12-16 14:41 +0100, Thomas Petazzoni spake thusly:

Quoted 31 lines · Vicente Olivert Riera

Quoted 29 lines

Quoted 17 lines

Quoted 7 lines

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

Quoted 7 lines

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

As 4.x is a LTS release I would not drop it for the 5.x release.

Quoted 7 lines

I would keep all the three version we have - they are all still maintained and v0.12 and v4 are both even LTS releases.

New versions are often not compatible with older versions of Node.js - it's similiar to Lua.

So I would lean toward 1.

I agree with you. Dropping a LTS version doesn't look good to me. We could do it when it's not maintained anymore. Right now I vote for keeping the three versions we already have plus adding the 5.2.0 because is the new stable: option 1.

Quoted 4 lines

I am personally not very happy with option (1). Keeping gazillions of versions means that we have potentially to test all those options. And the random testing done by the autobuilders does not work to randomize "choice" options, i.e we will never test the non-default versions.

Not completey true, since the higher versions ahve dependencies not always fulfilled (armv6+, gcc >= 4.8...) so, as we do randomize the CPU from time to time, we would eventually have all versions being built.

But I do agree that this is not the best situation. I would prefer if we could find a solution that does not imply having so many versions. I deeply believe that we should limit ourselves to just having 0.10.x and 5.2.x .

Quoted 9 lines

What is the motivation for keeping all those versions around? While I can understand that keeping 0.10.x around to have a fallback solution for ARMv5 platform is desired, I don't understand why we would keep 0.12.x and 4.2.x.

The fact that 0.12.x and 4.2.x are still maintained upstream as LTS versions is completely irrelevant. There are other projects that may maintain older branches as LTS, and still we don't support all the possible maintained versions.

Totally agreed. LTS status of uostream versions does not mean we should have all of them.

Quoted 2 lines

Are there incompatibilities between 0.12.x, 4.2.x and 5.2.x that prevent a user from easily upgrading?

Are all those versions API/ABI/whatevrer incompatible with each others? Or is it possible to narrow down the set of versions?

I.e. if 4.2.x and 5.2.x are compatible, there is no reason to keep 4.2.x, since 5.2.x is enough and does not have requirements more stringents than 4.2.x. And so on...

Regards,
Yann E. MORIN, in the train...

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 39 lines

Thomas, All,

On 2015-12-16 14:41 +0100, Thomas Petazzoni spake thusly:

Quoted 35 lines · Vicente Olivert Riera

Quoted 23 lines

Quoted 23 lines

Quoted 7 lines

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

Quoted 7 lines

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

As 4.x is a LTS release I would not drop it for the 5.x release.

I would keep all the three version we have - they are all still maintained and v0.12 and v4 are both even LTS releases.

New versions are often not compatible with older versions of Node.js - it's similiar to Lua.

Quoted 6 lines

Quoted 1 line

So I would lean toward 1.

I agree with you. Dropping a LTS version doesn't look good to me. We could do it when it's not maintained anymore. Right now I vote for keeping the three versions we already have plus adding the 5.2.0 because is the new stable: option 1.

I am personally not very happy with option (1). Keeping gazillions of versions means that we have potentially to test all those options. And the random testing done by the autobuilders does not work to randomize "choice" options, i.e we will never test the non-default versions.

Quoted 3 lines

Not completey true, since the higher versions ahve dependencies not always fulfilled (armv6+, gcc >= 4.8...) so, as we do randomize the CPU from time to time, we would eventually have all versions being built.

One point to note, 5.x also adds the requirement for wchar too which 4.x did not need.

Quoted 21 lines

But I do agree that this is not the best situation. I would prefer if we could find a solution that does not imply having so many versions. I deeply believe that we should limit ourselves to just having 0.10.x and 5.2.x .

Quoted 9 lines

What is the motivation for keeping all those versions around? While I can understand that keeping 0.10.x around to have a fallback solution for ARMv5 platform is desired, I don't understand why we would keep 0.12.x and 4.2.x.

The fact that 0.12.x and 4.2.x are still maintained upstream as LTS versions is completely irrelevant. There are other projects that may maintain older branches as LTS, and still we don't support all the possible maintained versions.

Totally agreed. LTS status of uostream versions does not mean we should have all of them.

Quoted 2 lines

Are there incompatibilities between 0.12.x, 4.2.x and 5.2.x that prevent a user from easily upgrading?

Quoted 6 lines

Are all those versions API/ABI/whatevrer incompatible with each others? Or is it possible to narrow down the set of versions?

I.e. if 4.2.x and 5.2.x are compatible, there is no reason to keep 4.2.x, since 5.2.x is enough and does not have requirements more stringents than 4.2.x. And so on...

There are api changes between the main versions. See
https://github.com/nodejs/node/wiki/API-changes-between-v0.10-and-v0.12,
https://github.com/nodejs/node/wiki/API-changes-between-v0.10-and-v4,
https://nodejs.org/en/blog/release/v5.0.0/ for example. Although these versions have some api changes you really need to keep up to date and are encouraged to upgrade.

Note, 5.3.0 was just released hence this patch set is already outdated.

Martin, All,

On 2015-12-17 17:29 +0000, Martin Bark spake thusly:

Quoted 40 lines · Yann E. MORIN

Quoted 39 lines

Thomas, All,

On 2015-12-16 14:41 +0100, Thomas Petazzoni spake thusly:

Quoted 35 lines · Vicente Olivert Riera

Quoted 23 lines

Quoted 23 lines

Quoted 7 lines

So, I think we have a few options here:

1) keep all the three existing versions, add 5.2
2) keep 0.10 and 0.12, replace 4.2 with 5.2
3) keep 0.10, ditch 0.12, replace 4.2 with 5.2
4) dith 0.10 and 0.12, replace 4.2 with 5.2

Quoted 7 lines

I would lean toward either 2 or 3.

3 is IMHO the best solution: 5.2 is the best choice when all the conditions are met; 0.10 is the fallback, maybe not the optimum in case 0.12 would have fit, but since that's a fallback I don't think it matters much...

As 4.x is a LTS release I would not drop it for the 5.x release.

I would keep all the three version we have - they are all still maintained and v0.12 and v4 are both even LTS releases.

New versions are often not compatible with older versions of Node.js - it's similiar to Lua.

Quoted 6 lines

Quoted 1 line

So I would lean toward 1.

I agree with you. Dropping a LTS version doesn't look good to me. We could do it when it's not maintained anymore. Right now I vote for keeping the three versions we already have plus adding the 5.2.0 because is the new stable: option 1.

I am personally not very happy with option (1). Keeping gazillions of versions means that we have potentially to test all those options. And the random testing done by the autobuilders does not work to randomize "choice" options, i.e we will never test the non-default versions.

Quoted 6 lines

Quoted 3 lines

Not completey true, since the higher versions ahve dependencies not always fulfilled (armv6+, gcc >= 4.8...) so, as we do randomize the CPU from time to time, we would eventually have all versions being built.

One point to note, 5.x also adds the requirement for wchar too which 4.x did not need.

Well, is that really an issue? I would be quite a bit surprised if people would really need to run nodejs on a system without wchar; basically, only uClibc can lack wchar, glibc and musl always have it, and I would contend that using nodejs on a uClibc system without wchar is just not supported.

After all, if one disables wchar in a uClibc toolchain means that one is vey tight on space on the target, and I doubt nodejs would even fit in sch a target.

So I'd say we don't care, and we'd still have 0.10.x as a fallback for that case.

Quoted 28 lines

Quoted 21 lines

But I do agree that this is not the best situation. I would prefer if we could find a solution that does not imply having so many versions. I deeply believe that we should limit ourselves to just having 0.10.x and 5.2.x .

Quoted 9 lines

What is the motivation for keeping all those versions around? While I can understand that keeping 0.10.x around to have a fallback solution for ARMv5 platform is desired, I don't understand why we would keep 0.12.x and 4.2.x.

The fact that 0.12.x and 4.2.x are still maintained upstream as LTS versions is completely irrelevant. There are other projects that may maintain older branches as LTS, and still we don't support all the possible maintained versions.

Totally agreed. LTS status of uostream versions does not mean we should have all of them.

Quoted 2 lines

Are there incompatibilities between 0.12.x, 4.2.x and 5.2.x that prevent a user from easily upgrading?

Quoted 6 lines

Are all those versions API/ABI/whatevrer incompatible with each others? Or is it possible to narrow down the set of versions?

I.e. if 4.2.x and 5.2.x are compatible, there is no reason to keep 4.2.x, since 5.2.x is enough and does not have requirements more stringents than 4.2.x. And so on...

Quoted 6 lines

There are api changes between the main versions. See
https://github.com/nodejs/node/wiki/API-changes-between-v0.10-and-v0.12,
https://github.com/nodejs/node/wiki/API-changes-between-v0.10-and-v4,
https://nodejs.org/en/blog/release/v5.0.0/ for example. Although these versions have some api changes you really need to keep up to date and are encouraged to upgrade.

So we should take thoe encouragements, and just upgrade. ;-)

Quoted 1 line

Note, 5.3.0 was just released hence this patch set is already outdated.

See, that's the issue. If we were to add all major and LTS nodejs versions, we'd now get 5 versions: 0.10.x, 0.12.x, 4.2.x, 5.2.x and now 5.3.x . This is definitely not viable in the long run.

So, my position, and I guess Thomas will agree: please respin this patch byt replacing 4.2 with 5.2, and a follow-up patch to get rid of 0.12.x. In the meantime, I'll mark this one as "Changes Requested" in our Patchwork.

Thanks! ;-)

Regards,
Yann E. MORIN.

--
.-----------------.--------------------.------------------.--------------------.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

'------------------------------^-------^------------------^--------------------'

Quoted 4 lines

So, my position, and I guess Thomas will agree: please respin this patch byt replacing 4.2 with 5.2, and a follow-up patch to get rid of 0.12.x. In the meantime, I'll mark this one as "Changes Requested" in our Patchwork.

Will do. I have an updated patch set ready, just need to do more testing.