#2751 Issue closed: RFC: Preparations towards a ReaR 2.7 release¶
Labels: fixed / solved / done, ReaR Project
jsmeix opened issue at 2022-02-02 08:37:¶
The last ReaR versions had been released about once a year, cf.
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
Version 2.6 (June 2020)
Version 2.5 (May 2019)
Version 2.4 (June 2018)
so the upcoming ReaR 2.7 release will be somewhat later than usual
but not too late because nowhere is stated we release once a year.
Therefore I would like to suggest
to start with preparations towards a ReaR 2.7 release.
The ReaR release process is described at
https://github.com/rear/rear/wiki/Release-process
I never did the whole ReaR release process myself
so I would need probably a lot of help.
I marked some issues where I personally think they should be fixed
before ReaR 2.7 can be released with the "blocker" label:
https://github.com/rear/rear/issues?q=is%3Aopen+is%3Aissue+label%3Ablocker
Also, when you are testing the pre-2.7 release make a note in our WIKI
page:
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.7---wip
jsmeix commented at 2022-02-03 08:37:¶
I will prepare the release notes on
https://github.com/rear/rear.github.com/tree/master/documentation
i.e. create a new release-notes-2-7.md there and update it,
see
https://github.com/rear/rear.github.com/pull/14
jsmeix commented at 2022-02-16 09:38:¶
I have set the due date for the ReaR v2.7 milestone to 2022 April 15.
That current due date mid April 2022 is only a tentatively estimated
intended date.
It is not at all meant as a date where ReaR users could currently rely
on.
pcahyna commented at 2022-02-16 09:40:¶
@jsmeix for me that's a good timeframe, I would like to contribute to the release effort in March (i.e. not in the upcoming two weeks).
jsmeix commented at 2022-02-16 09:46:¶
@rear/contributors
please tell if the current due date mid April 2022 for the ReaR v2.7
milestone
is not OK for you - we are free to change things as we need them for us.
jsmeix commented at 2022-02-16 10:31:¶
Because I added the milestone ReaR v2.8
and already assigned issues and pull requests to it, cf.
https://github.com/rear/rear/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22ReaR+v2.8%22
and
https://github.com/rear/rear/pulls?q=is%3Aopen+is%3Apr+milestone%3A%22ReaR+v2.8%22
I wonder about the following:
Shouldn't we allow also patch/bugfix versions if needed
e.g. a ReaR 2.7.1 to fix bugs in ReaR 2.7 before ReaR 2.8?
We had major.minor.patch version numbers in ReaR 1.x
but since ReaR 2.x we do no longer have them, see
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
Version 2.6 (June 2020)
Version 2.5 (May 2019)
Version 2.4 (June 2018)
Version 2.3 (December 2017)
Version 2.2 (July 2017)
Version 2.1 (June 2017)
Version 2.00 (January 2017)
Version 1.19.0 (October 2016)
Version 1.18.0 (March 2016)
Version 1.17.2 (August 2015)
Version 1.17.1 (June 2015)
I don't know the reason why we do no longer have major.minor.patch
but only major.minor
@rear/contributors
is there a reason why major.minor.patch causes problems for ReaR?
schlomo commented at 2022-02-16 11:10:¶
I honestly doubt that anybody has the time (or motivation) to back port fixes so that I would expect users of our Open Source tool to simply upgrade to the latest.
That is also the reason why (in my opinion) we don't have and don't need a minor version. We simply create a new minor version if we make a new release that fixes problems or adds features and a new major version if we believe that we changed so much that we are not sure about the general compatibility of previous configurations.
So for me there is no need for a patch version.
If a commercial vendor would like to spend the effort then of course they are welcome to do so, maybe they would have a business case (e.g. paying customers) for that. Of course ReaR developers working for such a vendor are welcome to host the patch release branches here in our main repo.
What do you think?
jsmeix commented at 2022-02-16 11:37:¶
I don't mean any backporting (of course I have no time for that
here at upstream - at SUSE we do some backporting for our
rear23a RPM in SLE-HA as specifically needed).
I meant if we need to release a subsequent ReaR version
after ReaR 2.7 of the current GitHub master code
to get some reasonably serious bugs or issues fixed
that we solved up to that point in time
then we would currently release it as ReaR 2.8
regardless that some issues that are assigned to the
ReaR v2.8 milestone would not yet be solved at that point in time.
I see now that this is not a real issue.
Before we release ReaR 2.8 we would create a new milestone ReaR v2.9
and move those ReaR v2.8 milestone issues that are not yet solved
to the new ReaR v2.9 milestone.
So also for me there is no need for a patch version.
pcahyna commented at 2022-02-16 11:44:¶
I don't mean any backporting (of course I have no time for that).
I think a patch version would make sense only with backporting. I.e. a version that has only fixes for known bugs and no new features and overhauls (that risk introducing new bugs and incompatibilities).
jsmeix commented at 2022-02-16 11:48:¶
FYI regarding the risk introducing new bugs and incompatibilities
see what I do at SUSE for ReaR in SLE-HA in the sections
"rear / rear116 / rear1172a / rear118a / rear23a" and
"SUSE support for Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
jsmeix commented at 2022-04-06 12:55:¶
I postponed the due date for the ReaR v2.7 milestone to 2022 May 17.
That current due date mid May 2022 is only a tentatively estimated
intended date.
It is not at all meant as a date where ReaR users could currently rely
on.
jsmeix commented at 2022-05-13 06:04:¶
Again I postponed the due date for the ReaR v2.7 milestone to 2022 June
21.
That current due date mid June 2022 is only a tentatively estimated
intended date.
It is not at all meant as a date where ReaR users could currently rely
on.
jsmeix commented at 2022-06-03 13:11:¶
FYI:
Things look good for a ReaR 2.7 release date mid June:
Currently
the only issue with label "ReaR v2.7" is
https://github.com/rear/rear/issues/2781
and the only pull request with label "ReaR v2.7" is
https://github.com/rear/rear/pull/2717
jsmeix commented at 2022-06-08 12:22:¶
I updated release notes for ReaR 2.7
in
https://github.com/rear/rear.github.com/pull/14
via
https://github.com/rear/rear.github.com/pull/14/commits/75a146f7240fa887a70568b85e81219828164022
To view that use
https://github.com/rear/rear.github.com/blob/75a146f7240fa887a70568b85e81219828164022/documentation/release-notes-2-7.md
jsmeix commented at 2022-06-21 07:56:¶
I set the ReaR 2.7 release date to end June 2022
see
https://github.com/rear/rear/milestones
ReaR v2.7
Due by June 28, 2022
jsmeix commented at 2022-06-28 10:44:¶
Because of
https://github.com/rear/rear/issues/2781#issuecomment-1168363028
I postponed the ReaR 2.7 release date to
beginning of July, see
https://github.com/rear/rear/milestones
ReaR v2.7
Due by July 12, 2022
jsmeix commented at 2022-07-07 13:09:¶
Because of
https://github.com/rear/rear/issues/2781#issuecomment-1177558312
and
https://github.com/rear/rear/pull/2831#issuecomment-1177577045
I postponed the ReaR 2.7 release date to
mid July, see
https://github.com/rear/rear/milestones
ReaR 2.7
Due by July 19, 2022
ReaR 2.7 release date is mid July 2022
jsmeix commented at 2022-07-12 13:17:¶
Hooray!
There are no real "blocker" things left for ReaR 2.7
(i.e. there is nothing left that needs code changes).
Currently there is only
https://github.com/rear/rear/pull/2819
and
https://github.com/rear/rear.github.com/pull/14
left.
jsmeix commented at 2022-07-13 11:54:¶
With
https://github.com/rear/rear.github.com/pull/14
and
https://github.com/rear/rear/pull/2819
merged right now
I will do further steps tomorrow
towards releasing ReaR 2.7 according to
https://github.com/rear/rear/wiki/Release-process
jsmeix commented at 2022-07-13 12:02:¶
@rear/contributors
because I never did the whole ReaR release process myself
I would very much appreciate it if you could have a look
and check if it looks OK to you what I do
in particular when you speak out early
if something looks fishy to you.
jsmeix commented at 2022-07-14 09:31:¶
So it seems by working through
https://github.com/rear/rear/wiki/Release-process
I released ReaR 2.7 right now.
In particular make obs OFFICIAL=1 did more than I expected:
ReaR 2.7 packages got built in openSUSE build service
for the same Linux distributions as ReaR 2.6 is built
from the source rear-2.7.tar.gz archive that is there
https://build.opensuse.org/package/show/Archiving:Backup:Rear/rear-2.7
The built ReaR 2.7 packages are available under
https://download.opensuse.org/repositories/Archiving:/Backup:/Rear/
There is now a new GitHub branch 'rear-2.7'
https://github.com/rear/rear/tree/rear-2.7
so the GitHub 'master' branch
https://github.com/rear/rear/tree/master
is free for further development.
jsmeix commented at 2022-07-14 09:33:¶
From my (limited) point of view
this issue should now be (hopefully) done
or at least "mostly" done.
@rear/contributors
please have a look and check if it looks OK to you what I did
and tell me if something went wrong or when something is missing.
jsmeix commented at 2022-07-14 10:50:¶
I also (manually) updated
https://build.opensuse.org/package/show/Archiving:Backup:Rear:Snapshot/rear-manual-snapshot
and its build results appear under
https://download.opensuse.org/repositories/Archiving:/Backup:/Rear:/Snapshot
But I don't know how
https://build.opensuse.org/package/show/Archiving:Backup:Rear:Snapshot/rear-github-master
and
https://build.opensuse.org/package/show/Archiving:Backup:Rear:Snapshot/rear
work so I left them as is.
jsmeix commented at 2022-07-14 11:55:¶
I updated
https://build.opensuse.org/package/show/Archiving/rear
where its build results appear under
https://download.opensuse.org/repositories/Archiving/
and I submitted it to openSUSE:Factory as
https://build.opensuse.org/request/show/989146
pcahyna commented at 2022-07-14 12:47:¶
There is now a new GitHub branch 'rear-2.7'
There are also rear-2.7 and 2.7 tags, so the release is done from
the version control POV. (The duplicate tag has been there also for the
older releases.) Thanks for taking care of this!
jsmeix commented at 2022-07-14 13:06:¶
Two tags rear-2.x and 2.x exist according
to the section "Tag version in master branch" in
https://github.com/rear/rear/wiki/Release-process
jsmeix commented at 2022-07-14 13:11:¶
I close this issue to get
https://github.com/rear/rear/milestone/18
done.
jsmeix commented at 2022-07-14 13:14:¶
I also closed
https://github.com/rear/rear/milestone/18
So ReaR 2.7 should now be done - at least regarding GitHub.
@rear/contributors
if this or that things are missing outside of GitHub
please tell me.
hpannenb commented at 2022-07-14 13:29:¶
@jsmeix thank You so much for the effort and time spent to build this release and of course to all contributors of this project. Happy birthday to ReaR 2.7. :-)
gdha commented at 2022-07-14 14:00:¶
@jsmeix A job well done! I can relax now...
jsmeix commented at 2022-07-15 07:02:¶
@hpannenb @gdha
thank you for your plaudits!
Let's wait and see and hope that ReaR 2.7
actually does work well for our users
in practice out there in the wild.
I am a bit nervous because we did so many fixes and
enhancements for ReaR 2.7 (two years since ReaR 2.6)
that there might be accidentally introduced regressions
which we couldn't foresee but which are severe for our users
so I will wait some weeks until I can relax.
[Export of Github issue for rear/rear.]