ECLiPSeWiki | Build / Admin

Git branching model for ECLiPSe

Branches:

master
 	this is where development of the next version x.z happens.

patches_x_y
 	this is where fixes are committed to after x.y was released.

builds_master
builds_x_y
 	commits to these branches are done exclusively from the
	build&test mechanism: it merges the changes from the corresponding
	development branch (master or patches_x_y) and commits these
	together with a build number when they integrate successfully.



----<dev v1>---[rel v1]----<dev v2>----[rel v2]----<dev v3>------ master
  \          \    \      \           \    \      \          \
 <bld>------<bld>--\----<bld>-------<bld>--\----<bld>------<bld>- builds_master
                  \ \                     \ \
                   \ \                     \ \
                    \ \                     \ \------<fix>------- patches_v2
                     \ \                     \   \           \      
                      \ \                     \-<bld>-------<bld> builds_v2
                       \ \
                        \ \
                         \ \-----<fix>--------<fix>-------<fix>--- patches_v1
                          \   \           \           \           
                           \-<bld>-------<bld>-------<bld>-------- builds_v1

This looks quite complicated. The point of having the build_xx branches is to track the build number without interfering with the regular commits.

Initial setup

	git checkout master
	<set version>
	<set buildno=0, stage=development>
	git commit -a -m "Init version&buildno"
	git branch builds_master

Making changes

Fixing a bug:

	git checkout patches_vi
	<edit>
	git commit -a -m "Fix bug"

New development:

	git checkout master
	<edit>
	git commit -a -m "Implement feature"

Doing a build

All builds are to be done on a build branch!

A slave build, i.e. just re-building the latest release/build:

checkout builds_x_y (or builds_master)
build and test

A new build to incorporate recent changes and increment the build number (as done by the BUILD_ROTD script):

checkout builds_x_y (or builds_master)
merge patches_x_y (or master)
increment build number in version.pl
build and test
if successful, commit build number

	git checkout builds_{master|vi}
	git merge --no-commit {master|patches_vi}
	<increment buildno in version.pl>
	git add <version_file>
	<build and test>
	git commit --untracked-files=no -m "Build #"

Merge patches_x_y branch into master

Make sure patch branch has been pushed to central repository.
Go to a clean master-workdir.
Get the up-to-date patch branch from the central repository:

      git fetch

Merge it into master

      git merge --no-commit origin/patches_7_0

Resolve conflicts.
Check that version numbers (various files) are not affected.
Check that version.pl isn't changed.
Check files that had no conflict, but were modified in both branches.
Call autoconf to re-make configure from configure.ac.
Re-make Kernel/lib/*.eco bootfiles using make new_bootfiles, and check whether the result is similar to the merged versions (to be safe, use the newly created eco files rather than the merged ones).

Making a Release

What has to be done at a release x.y point:

create a new branch patches_x_y (from last master commit)
on master, increment version number from x.y to x.z
commit master
create a new branch builds_x_z (from that master commit)

Note: The build number in master and patches_x_y branches always remains 0:

	sepia_stage("development").
	sepia_build(0).

Whereas in the builds_x_y branches:

	sepia_stage("beta" or "").
	sepia_build(1..999).

Release:

	# Mark as 'beta' in builds_master
	git checkout builds_master
	<set stage=beta, keep buildno>
	git commit -m "Mark as beta-release" <version_file>

	# Do a build (how to force?). If successful:

	# create the version-specific branches
	git branch patches_vi master
	git branch builds_vi builds_master

	# Update version number on the master branch
	git checkout master
	<increment version, see below>
	git commit -a -m "New version"

	# Reset build number for master branch builds
	git checkout builds_master
	<set buildno=0, stage=development>
	git commit -m "Reinit buildno" <version_file>

This simplified procedure should also work (2022, not tested):

	# create the version-specific branches
	git branch patches_vi master
	git branch builds_vi builds_master

	# Mark as 'beta' in new builds branch
	git checkout builds_vi
	<set stage=beta, keep buildno>
	git commit -m "Mark as beta-release" <version_file>

	# Update version number on the master branch
	git checkout master
	<increment version, see below>
	git commit -a -m "New version"

	# Reset build number for master branch builds
	git checkout builds_master
	<set buildno=0, stage=development>
	git commit -m "Reinit buildno" <version_file>

Currently the ECLiPSe version number is scattered through a whole bunch of files in the distribution, and a check should be made to make sure they've all been updated. This information should be centralised, but until that is done, here is a (possibly out-of-date) list of places it occurs (look for X.Y and X_Y):

	configure.ac
	configure (run autoconf after changing configure.ac)
	documents/texinputs/sepiachiphtml.tex
	documents/tutorial/mapdebugdemo.tcl
	ecl_inst.tcl
	ecl_inst.js
	lib_tcl/eclipse_tools.tcl
	lib_tcl/example.tcl
	lib_tcl/example1.tcl
	lib_tcl/mapembed.tcl
	lib_tcl/mapremote.tcl
	lib_tcl/tkeclipse.tcl
	lib_tcl/tktools.tcl
	Kernel/src/eclipse.reg