Prepare for release ReaR v2.4

[gdha]

The purpose of this issue is to have a landmark (sic) so we can brainstorm
which of the current issues with milestone of v2.4
https://github.com/rear/rear/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22ReaR+v2.4%22
we keep and resolve and which we move forward to milestone v2.5.

We can also make a list of points which might be important in the preparation of a new release.

Shall we aim for end of May 2018 to have a final cut-off and prepare for a new release?

[gdha]

@schlomo @jsmeix @gozora @schabrolles Shall we try to concentrate on the label 2.4 only. New issues should not get resolved for 2.4, but pushed back to 2.5 or later.
The only new issues that may get attention are serious security breaches. Otherwise, we never get a new release out of the door (as scheduled).

[jsmeix]

The only issue that actually worries me is issue 1769 starting at
#1796 (comment)
because it is about a SLES12 system with an unusual btrfs structure
where "rear recover" does not work which contradicts my intent
that "rear recover" does work generically for any valid btrfs structure,
cf. #1368 (comment)

[jsmeix]

From my point of view
#1796 (comment)

With the current ReaR GitHub master code it does no longer work
to recreate a SLES12-GA/SP0 system

blocks the ReaR 2.4 release.

[gdha]

@jsmeix Is the block released or still present at this point in time?

@rear/contributors We are almost at the end of month May which was defined as a milestone to accept PR for 2.4. The first two weeks of June we can use to test our candidate release 2.4 as much as possible and only fix issues coming out from these tests.

Please keep in mind that from June, 1st on all new Pull Requests will be headed for 2.5.

[jsmeix]

@gdha
since #1813 was merged it works again
to recreate a SLES12-GA/SP0 system whith its default btrfs structure
so that from my point of view nothing blocks the ReaR 2.4 release.

I will have a look at the new ReaR 2.4 release notes
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-4.md

[gdha]

@jsmeix I have delay in writing the release notes - too much to do with docker/rancher stuff for a customer. Give me 'till end of the week.

[jsmeix]

@gdha
no worries - take your time.
Issues from customers (who in the end pay my salary)
always have higher priority also for me.

[jsmeix]

I enhanced the ReaR 2.4 release notes at
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-4.md

[jsmeix]

@gdha
a proposal for future release notes,
in particular for the next ReaR 2.5 release notes:

I propose the following:

Directly after ReaR 2.4 was officially released
the next ReaR 2.5 release notes file
https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-5.md
should be created with the appropriate headers for ReaR 2.5 (but with empty content) like

Preliminary work-in-progress Release Notes for the future Relax-and-Recover version 2.5

...

Version 2.5 (currently no planned release date)

Abstract

New features, bigger enhancements, and possibly backward incompatible changes:

...

Details (mostly in chronological order):

...

During ReaR 2.5 development that ReaR 2.5 release notes file
should be filled step by step as needed with ReaR 2.5 content.

This way we would during ReaR 2.5 development maintain and provide
a reasonably up-to-date summary about new features, bigger enhancements,
and possibly backward incompatible changes.

I think we would benefit from a continuously developed release notes file
because then it should be mostly done when the release date is there.

Additionally our users who use our current ReaR upstream GitHub master code
would benefit from a continuously developed release notes file because they
would get a central place where they could read an up-to-date summary about
new features, bigger enhancements, and possibly backward incompatible changes
without the effort to compile that information out of the git commit messages.

For an example where such information was probably missing for a user
who tried our current ReaR upstream GitHub master code see
#1822 (comment)
and
#1822 (comment)

[gdha]

@jsmeix Excellent idea to start with release notes for 2.5 right after the release of 2.4.
@jsmeix Thank you for updating the the Test Matrix 2.4
@schabrolles Do you have some updates for PowerVM and/or PPC64(le) recovery tests for the Test Matrix 2.4?
@rear/contributors Any blockers left over? if not, I think we are almost ready to prepare a new release?

[jsmeix]

@gdha
no blockers left from me so that for me it looks o.k. to release version 2.4

[schabrolles]

@gdha @jsmeix I'm gonna start some test on migration with PowerVM this afternoon. I'll update the wiki for 2.4 Matrix.

[gdha]

I just pushed rear-2.4 into Fedora stack and uploaded it to SourceForge. This evening I will do the OBS part (no time in the afternoon).

[gdha]

With ReaR 2.4 being released I can finish off this task with the rear-2.4 branch.