20

As I understand, the term "Backporting" is used to describe a fix which is applied in a future version which is also ported to a previous version. Wikipedia definition is as follows:

Backporting is the action of taking a certain software modification (patch) and applying it to an older version of the software than it was initially created for. It forms part of the maintenance step in a software development process...

For example:

  • A problem is discovered and fixed in V2.0. The same fix is ported and applied to V1.5.

What is the term when this is done in the opposite direction?

  • The problem is discovered and fixed in V1.5. The same fix is ported and applied to V2.0.

Would the term "Backporting" still apply? Or is there a term such as "Forwardporting" (which amusingly sounds a lot like "Port Forwarding")?

  • 1
    What about "propagating"? – Gill Bates Sep 26 '16 at 12:22
28

It's the same as the opposite of a backslash. Everyone wants to call it a forward slash, but really it's just a "slash." The opposite of backporting is simply "porting."

  • "Porting" is a more general term and can apply to any code transfer, even between languages. In my company we use "forward-porting" for the specific case described in this question. – Marko Topolnik Aug 10 '16 at 18:10
14

This does not generally happen as you would fix said issue in the V2.0 codebase, and optionally backport it. :) In terms of version control, this is simply called merging.

  • 3
    This does happen because V1.x and V2.x coexist and are maintained in parallel, each on its own maintenance branch. A cross-version bug can be discovered and fixed on any side. – Marko Topolnik Aug 10 '16 at 18:11
  • 3
    If V1.5 is already released, but V2.0 will be released in the future, then you first fix the issue in V1.5, because this version is already used by customers and needs the fix more urgend. Afterwards you port the fix to V2.0. – user1364368 Jun 3 '17 at 17:13
  • @user1364368 release management is an orthogonal concern. it makes more sense to fix the bug in the most recent version of the codebase as it contains more information (its change history is a superset of the older version's change history). think about it a different way: disregard that the change is related to a bug. would you still prefer to introduce changes in an older version? would you, say, start feature development in an older version of the codebase? this very quickly reduces to a nonsensical, backward-recursive development strategy – awdz9nld Jun 4 '17 at 18:36
  • @MartinKällman The head of the codebase (for V2.0) might be (due to current development work) in a state that doesn't allow it to develop the fix. It might take days or weeks until the head of the codebase is clean again, but you cannot wait so long for the emergency correction. – user1364368 Jun 5 '17 at 20:06
1

I guess I would use the terms: future-proofing or, alternatively, forward compatibility:

From Wikipedia future-proof:

Future proof: The phrase future proofing describes the exclusive process of trying to anticipate future developments, so that action can be taken to minimize possible negative consequences, and to seize opportunities.

And forward-compatibility:

Forward compatibility or upward compatibility (sometimes confused with extensibility) is a compatibility concept for systems design, as e.g. backward compatibility. Forward compatibility aims at the ability of a design to gracefully accept input intended for later versions of itself.

Or both "future-proofing through forward-compatibility".

Oh the buzzwordry :)

0

Backporting in the opposite direction is just porting, but there's no reason to do that in the context you describe.

0

I think the term "backport" refers only to the action of bringing a feature of a new release of a program to an older of the same program, for the benefits of still using it.

As you don't develop new feature on old, closed, versions no "reverse" backporting exists (if you are, by definition, the version is not old).

What you're calling a "forwardport", fixing a problem both in an old and a new verion, is a mere bugfix or patch.

-1

There is not a commonly used term for merging a set of changes from an older branch of software to a newer one. Unless the latest branch of the software is highly unstable most developers will develop bug fixes on the latest branch of the software regardless of what version the bug was found in. This is done in order to reduce merge conflicts since the latest branch of the software changes more frequently than older branches. Any software bug reported by a customer is by definition reported in an earlier version than it is fixed in since the customer doesn't have access to the latest branch of your software.

  • true unless your customer wants a fix NOW. – Alex R Jul 14 '17 at 23:07
-1

I came here looking for an answer because I'm writing a commit comment for this very scenario. Given the lack of actual jargon for this common situation, I'm just going to spell it out as "merging production hotfixes into dev branch".

Not the answer you're looking for? Browse other questions tagged or ask your own question.