-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/26/2013 04:35 AM, Matthias Runge wrote:
On 26/09/13 10:21, Tomas Hrcka wrote:
> Hello fedora noders,
>
> at first I want to thank you for great amount of work you did to
> get node to fedora. Good job!
>
> I am poking around nodejs and v8 for few months, and there are
> few things... Is there a reason why do we have this old version
> of v8 in fedora? I know that stable branch of node is using it.
> But 0.10.* releases should run well also on newer v8. I started
> rewrite of v8.spec to use gyp and new stable release of v8, once
> finished I will publish it for review (since I am new to
> packaging this may take some time).
>
> Why do we have stable release of node in fedora? I know its
> stable, but we are devs distro should we have latest nodejs that
> is out there? People are using 0.11 branch for development
> despite the fact that it is not stable.
>
> I am offering my help here with both v8 and/or node and its
> modules so if you have too much packages feel free to add me as
> co-maintainer and I will do my best so we can deliver great
> distro with latest nodejs and modules.
>
Just very short: there is no need to put an updated v8.spec up for
review (if you don't want to make a version to be installed in
parallel to the older one).
Regarding using a development version of software foo in Fedora, I
thought it's discouraged to do so. Sadly, I can't find the
reference to it in the wiki. Especially, we need to take care not
to break compatibility during updates, see
http://fedoraproject.org/wiki/Updates_Policy
If we have it on good authority that 0.12.0 will be released in time
for (or near after) the release of Fedora 21, I have no problem with
upgrading the copy in Rawhide to use 0.11.x.
The reason we need a stable version of Node.js in the release is that
we're treating it like a standard runtime (i.e. Java JRE or Python or
Ruby runtimes). These can't change API/ABI compatibility within a
Fedora release or it can negatively affect all packages that depend on
it (and with Node.js, that's at least dozens).
Alternately, we could start maintaining a COPR repo for development
versions of Node.js. That might be the best approach, as it allows us
to keep a stable release in the base install. If you want to produce a
set of SRPMs for v8, libuv, Node.js, npm and the set of nodejs-*
packages necessary to accomplish this, I'll create a COPR build system
for f19 and F20 (I think we can reasonably abandon F18 at this point
for development versions).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlJEIR8ACgkQeiVVYja6o6MACwCeIRRlRMY2vtjR1wVKK/Dz+AmC
sw0AoKEVwxN2wr1tAC3tmX+Tc2Q7BoCE
=HNBn
-----END PGP SIGNATURE-----