#72 Changing branching model in git repo of this project

[Michael Paquier]

Commit db33f5 proves that managing this project on a single branch is very dangerous for code readability and maintenance as this currently enforces to create a bunch of ifdef blocks based on PG_VERSION_NUM directly inside the code. Up to 9.2 this might have been fine as the page format did not change much but since 9.3 this has impacted the function specs.

Hence I think that this code should change its branch format like that:
- Create a new branch called REL_STABLE_OLD for the code older that 9.2.
- Create a new branch called REL9_3_STABLE, for the code that can be built based on branch REL9_3_STABLE of PostgreSQL or PostgreSQL 9.3.X builds.

Each time Postgres created a new stable branch, this project should do the same.
This would also deeply facilitate release by having one major release based on one stable branch, for example:
- REL9_3_STABLE produces pg_rman 1.3.X
- REL_STABLE_OLD produced pg_rman 1.2.X
Future branch like that would work as well:
- REL9_4_STABLE will produce pg_rman 1.4.X

Other projects like pgpool, pgodbc, pgjdbc already use such a branching model.

At the same time, all the version related references in the code should be removed in the newly-created branches and master branch to facilitate the code.

[Takashi Ohnishi]

Hi,

I have divided branches as belows.

• master
• REL9_4_STABLE : this supports PostgreSQL 9.4
• REL9_3_STABLE : this supports PostgreSQL 9.3
• REL9_2_STABLE : this supports PostgreSQL 9.2
• pre-9.2 : : this supports PostgreSQL 9.1 and before

In addition, I have removed code with PG_VERSION_NUM from REL9_*_STABLE.
Though master and pre-9.2 has still such codes, I will remove them from master branch in development for PostgreSQL 9.5.

Regards,

[Michael Paquier]

Oh, thanks! I am going to update my stuff as well using this new infrastructure!