versioning / tags of candi releases

[tjhei]

I would like to propose that we tag versions of the form v<deal.II version>-r<Y> for example v9.0.0-r1. This allows us to precisely specify a version, which is helpful for the docker images dealii/docker-files#21
This means we can have more than one "blessed"/"released" version for a deal.II version, so we can update library versions, fix bugs, etc..

@koecher are you okay with this?

[koecher]

Awesome and I fully support this.

In the recent past I tried to do this by hand as best possible - but I certainly missed ones (such as deal.II v8.2.0).

We need to do this, since this clarifies which candi (tag) version works with which deal.II release (or development release) and helps to reference this for Software Journals such as Elsevier SoftwareX.

[tjhei]

Alright, what do we want users to get when they type in "git clone ..."? By default they currently get the master branch, which is not one of the "releases". If we want to change that we could:

• develop everything on a branch called "develop"
• when tagging a release we update master to point to the newest release

That is not very intuitive for us and maybe too much hassle. This means master is also less tested, which is a problem. Maybe leave things as is and if somebody complains let them do "git checkout v9.0.1r2" or something?

[koecher]

Well, thats correct Timo.

But sometimes it is very useful to have certain commits added to a stable release. Those should be selected by special "software-engineering" guys of the group, I suppose.

For instance, we had under our current developments in my software two issues with deal.II (obvious programming errors) which are not reflected by v9.0.0 and will not be reflected by v9.0.1. But on the other hand, this software (must be) is used by non-software guys, which we want to give only candi and a local.cfg which will work. This is my idea behind this PR.

[koecher]

Sorry @tjhei. I've messed up 2 different discussions with you. (my last comment does not make sense here, but I keep it for the history - cf. #102)

Indeed, currently we have candi-master as the working version of candi with the last stable deal.II version, but we can change the documentation easily to do

git clone https://github.com/dealii/candi
cd candi
git checkout "last stable tag"

[koecher]

As I said, as best possible I've tried to match the candi versions with deal.II versions, but I missed some places.

For instance, we do not have a working release version for deal.II v9.0.0

We need to stabilize this in future, thus I fully support your issue.

[koecher]

Alright, I've tagged to my best knowledge v9.0.0 and v9.0.1 and put a note into README.md to checkout v9.0.1 before running candi.sh.

Furthermore, we should tag everything aligned to deal.II tags for candi to make sure that we have exactly the candi version for release candidates etc.

[tjhei]

checkout v9.0.1 before running candi.sh.

I think tagging as v9.0.1 is not the correct thing to do as there will be more than one version that is the defacto version for deal.II 9.0.1. For that reason I would:

1. create branches dealii-9.0 (and later dealii-9.1 etc.) and advertise these to checkout by the user.
2. tag releases as v9.0.1r1, v9.0.1r2, etc..

[koecher]

Well, and thank you @tjhei for your comment, but I see deal.II v9.0.1 as a release from the past.

For the future we should do this more complicated way of branching and tagging.

[koecher]

PS. I think we should not spent to much time with candi, as it is simply a tool to make a download & compile & install as easy as possible.

[koecher]

After a long personal discussion with @tjhei we changed some versioning/branching methods for candi to be aligned with the deal.II repo and to allow for candi subreleases to create docker images from fixed and stable candi versioning tags.