Should BusyBox and uClibc also make a "flag version" likeEmbedded Linux?

[Cathey, Jim]

>My fear is that often the reason for using very outdated
>version of busybox is different: it's simply lack of
>time/resources to migrate.

Mixed with a healthy serving of "if it ain't broke,
don't fix it".  Usually the charter of the target is
not "deploy BB to the customer base", it's "deploy a
toaster to the customer base".  The fact that BB is
helpful in some way towards making toast is nice, and
that's why it's there, but evolution of BB isn't usually
necessary for the cooking of bread.  A stable product
doesn't usually welcome gratuitous updates.

It's when BB can be blamed for burnt toast that the
'lid comes off the box', and then one may reasonably
consider updating.  But if BB v20 is notably bigger
than BB v2, as configured, that could be a problem.
Especially if the toaster were quite resource-constrained.
And spending more ROM bytes on infrastructure like BB is
usually much less attractive than spending them on direct
features.

'Stale' software is a fact of life in embedded world.
We prefer to pronounce it 'stable', however!

-- Jim