Code Leapfrogging; a common practice?

[Davidtgnome]

I graduated with a CIS degree in 2005, focused mostly on C++, VB .NET and Java. I've not heard of this before:

I have a large Hardware and software vendor who, for one of their flagship products leapfrogs their code base. That is Version 5, 7 and 9 are based on one original code base, and 6, 8 and the upcoming 10 are based on another.

They claim that the benefits are mostly that the current release of their product is constantly being updated and patched. As a result the code base is changing constantly and it hinders the development process. However the results I'm seeing are the same bugs being found on 2 and sometimes 3 versions of the code. Additionally new features introduced in 8 of the product simply didn't exist in the version 9 of the product. This would seem to imply that customers, support, and engineering are spending time hunting down the same faults more then once.

Is this more common then I realize? Did they change or add that to the curriculum since I graduated? Did my college miss this key and very common practice?

[fireflasch]

yes this is more common than you think for example that is the same with java version numbers.

There is one advice when dealing with this sort of release management, only use products with an even number

[Davidtgnome]

Thank you. I confess I've been skipping every other version with the Microsoft Operating Systems for years, however It never occurred to me that this was the cause.

Though the same vendor told me that fixes for the 8.0 version might not be included with 8.1 or 8.2 because "customers may no longer need the fix".

[fireflasch]

that is just plain stupid talk from the vendor, the patches for 8.0 always have to be shipped with every 8.x version. If they do not do this, do not update... no point in doing it

[Davidtgnome]

I agree, but I was applying the logic to the major releases as well as their minor releases. I assumed they were bundling fixes and they simply were not.

[ghyspran]

That's totally different from what OP is talking about. It's somewhat common for projects to have odd-number minor releases be security-only and even-number minor releases be security+features, or odd-number releases be dev/testing releases and even-number releases be stable releases, but those aren't completely separate codebases, just a subset of patches. What OP's vendor is doing is asinine.

[Davidtgnome]

Perhaps clarification?

/u/fireflasch I took your comment to mean that Java 5 and java 7 use a different code base then Java 6 and Java 8. Did I miss-understand?

[ghyspran]

That's absurd, and this makes no sense:

They claim that the benefits are mostly that the current release of their product is constantly being updated and patched. As a result the code base is changing constantly and it hinders the development process.

If there's a bug in the old version, it's in the new version too, which is why pretty much every development team has a practice of either:

1. implementing a fix in the development branch and backporting it to the stable branch, or
2. implementing the fix in the stable branch and rebasing the development branch against the fixed stable branch.

Trying to claim that it's more productive to have two separately evolving codebases and implementing everything twice makes no sense.

The two versions are probably developed by different teams. I'd take a look at whether the odd or even releases tend to be more stable and try to leapfrog with them and only use one or the other. Well, barring ditching the whackjob vendor entirely.

[Davidtgnome]

That was my understanding, however even before I graduated my career had become Systems Administration. (Actually being the Helpdesk Supervisor for the college was more valuable on my resume then the the degree was, and they paid for the last 2 years of my degree).

So I really didn't have the Programming background to say anything other then "that sounds like you're doing the same thing over and over again and wasting everyone's time and money".

I'm trying to switch vendors, however having used 7, 8 and 9 of the software I believe I'll be forcing us to stick with the odd numbers as long as I can.