[j-nsp] Stable Junos

[Mark Tinka]

On Wednesday, September 01, 2010 04:51:19 am Richard A 
Steenbergen wrote:

> It's like playing JUNOS Hero, you don't ever catch the
> dragon. :)

Nope, you never do :-).

> Personally I'd like them to support JUNOS images for a
> bit longer. By the time a particular branch is actually
> stable enough to use without major issues (R4) it's
> already EOL, which means they refuse to build fixes for
> any newly discovered bugs after that. Infact for the
> last several releases they've actually released R4
> *AFTER* the EOL date, so you're guaranteed that anything
> you find wrong in R4 will never get fixed. This forces
> you to chase the next newer version of code to fix those
> last few issues, where for every 1 thing they fix they
> break 2 new things, then rinse and repeat forever.

I was actually thinking about something like that. Perhaps 
it might not be such a bad idea to have additional releases 
of a particular code base, e.g., R5, R6, R7, e.t.c., while 
development continues for newer releases (I know these are 
the so-called Service releases, but...).

In many cases, you have all the features you need for a 
particular release and just require only bug fixes to 
smoothen the code out.

> By the time 10.4 actually gets stable
> enough to use in widespread deploys, which is at least a
> year from today, where will be some other reason why
> we're forced into something newer. There always is. :)

And that is exactly my problem with JUNOS.

At the moment, bug fixes and new features are being coupled 
together (save for the Service releases et al). It would be 
nice if these two aspects would be sufficiently separated.

We all know R1 and R2 releases tend to be fairly high-risk, 
and that anything decent is R3 or later. It's simply 
terrible that we have to knowingly run buggy code just so we 
can fix a problem from a previous release or have that new 
feature that we can only get in a new release, and still be 
mindful of the fact that we might not be able to do anything 
serious about it for at least another 6 to 9 to 12 months or 
so, if we're lucky.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100901/fd8b8b77/attachment.bin>