30

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")?

Improve this question
1
  • 2
    What about "propagating"?
    – Gill Bates
    Sep 26, 2016 at 12:22

7 Answers 7

Reset to default
34

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."

Improve this answer
1
  • 1
    "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, 2016 at 18:10
13

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.

Improve this answer
4
  • 4
    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, 2016 at 18:11
  • 7
    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, 2017 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, 2017 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, 2017 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 :)

Improve this answer
0

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

Improve this answer
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.

Improve this answer
0

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".

Improve this answer
-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.

Improve this answer
1
  • true unless your customer wants a fix NOW.
    – Alex R
    Jul 14, 2017 at 23:07

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