From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] package/nodejs: Add version 5.2.0
Date: Wed, 16 Dec 2015 14:41:40 +0100 [thread overview]
Message-ID: <20151216144140.3b3224c5@free-electrons.com> (raw)
In-Reply-To: <56714A65.80301@imgtec.com>
Hello,
On Wed, 16 Dec 2015 11:26:29 +0000, Vicente Olivert Riera wrote:
> >> 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.
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?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-12-16 13:41 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
2015-12-16 13:41 ` Thomas Petazzoni [this message]
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=20151216144140.3b3224c5@free-electrons.com \
--to=thomas.petazzoni@free-electrons.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