From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] package/nodejs: Add version 5.2.0
Date: Wed, 16 Dec 2015 11:26:29 +0000 [thread overview]
Message-ID: <56714A65.80301@imgtec.com> (raw)
In-Reply-To: <1450132540.4928.24.camel@embedded.rocks>
Dear all,
On 14/12/15 22:35, J?rg Krause wrote:
> On Mo, 2015-12-14 at 22:10 +0100, Yann E. MORIN wrote:
>> Thomas, All,
>>
>> On 2015-12-14 21:43 +0100, Thomas Petazzoni spake thusly:
>>> On Mon, 14 Dec 2015 20:24:30 +0000, Martin Bark wrote:
>>>> 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?
>>>
>>> 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...
>>
>
> 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.
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.
Regards,
Vincent.
next prev parent reply other threads:[~2015-12-16 11:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 19:44 [Buildroot] [PATCH 1/3] package/nodejs: Add version 5.2.0 Martin Bark
2015-12-14 19:44 ` [Buildroot] [PATCH 2/3] package/nodejs: Fix uClibc-ng support Martin Bark
2015-12-14 19:44 ` [Buildroot] [PATCH 3/3] package/libuv: Fix support for uClibc-ng Martin Bark
2015-12-14 20:09 ` [Buildroot] [PATCH 1/3] package/nodejs: Add version 5.2.0 Thomas Petazzoni
2015-12-14 20:24 ` Martin Bark
2015-12-14 20:43 ` Thomas Petazzoni
2015-12-14 21:10 ` Yann E. MORIN
2015-12-14 21:31 ` Martin Bark
2015-12-14 21:49 ` Yann E. MORIN
2015-12-14 22:35 ` Jörg Krause
2015-12-16 11:26 ` Vicente Olivert Riera [this message]
2015-12-16 13:41 ` Thomas Petazzoni
2015-12-16 16:39 ` Yann E. MORIN
2015-12-17 17:29 ` Martin Bark
2015-12-17 18:27 ` Yann E. MORIN
2015-12-17 19:55 ` Martin Bark
2015-12-17 20:05 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56714A65.80301@imgtec.com \
--to=vincent.riera@imgtec.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox