Prepare release 9.3.3

[bourtemb]

Task list:

• Read/review steps listed in the "Releasing a new version" documentation for making a release
• Bump the version (if not already done) on tango-9-lts branch
• Merge the wished Pull Requests into tango-9-lts (Make sure Travis and appveyor are OK on the PR before the merge)
• Make sure the documentation is updated (readthedocs, doxygen)
• Make sure Travis and appveyor are OK on tango-9-lts branch
• Edit the CHANGELOG.md file
• Edit the RELEASE_NOTES file
• Create a release tag on GitHub, from tango-9-lts branch. Flag it as a pre-release.
• Advertise the pre-release on the mailing list to ask for feedback and testers
• Wait for at least 2 weeks before to do the next steps to give some time to get feedback from the first testers
• If no major bug was reported, the GitHub release can be flagged as "Latest release",
  else the bugs should be fixed first and a new pre-release should be created.
• Add Windows installers as assets to the GitHub release
• Generate Doxygen documentation for this new release and update cppTango-docs with the new generated documentation
• Update cppTango version in TangoSourceDistribution repository
• Release a new version of the TangoSourceDistribution
• Upgrade tango-cs docker and eventually tango-db docker (if a new version of TangoDatabase has been released).
• Advertise the release as the new stable release on the mailing list and on the tango-controls website (News)
• Close this issue

[bourtemb]

Let's try to do something similar as our experimented friends from PyTango and take this opportunity of a new cppTango release to document/agree on the process to make a release.
This issue is there to inform the community that a new release is in preparation.
I submitted tango-controls/tango-doc#264 where the above steps are described with more details.
Please do not hesitate to comment on this tango-controls/tango-doc#264 Pull Request if you want to suggest improvements, add steps and fix mistakes.
This is the first time we try to formalize these steps so there are some beginner mistakes probably here and there.
You can of course discuss here everything related to this release preparation.

[Ingvord]

I would suggest to delete RELEASE_NOTES file and use GitHub releases for that as discussed in #519. And instead of Edit the RELEASE_NOTES file say Edit the RELEASE_NOTES and move it down the road after the tag is there, so basically switch these two

[Ingvord]

And also move "Releasing a new version" documentation from read-the-docs to wiki of this repo, 'cauz it really belongs to this repo

[bourtemb]

I personally think it's a good thing to have the RELEASE_NOTES provided with the source code.
It also helps in the preparation of the release because we can improve/review the release notes in a Pull Request.
Once the RELEASE_NOTES are approved, and when the Github release is created, we can copy the RELEASE NOTES in the Github release description...

And also move "Releasing a new version" documentation from read-the-docs to wiki of this repo, 'cauz it really belongs to this repo

Well, I followed the example from PyTango on that one.
The advantage of having it on readthedocs is that again, we can discuss/review the documentation before it is online via Pull Requests.
Maybe the current location in the readthedocs documentation could be improved too?
The wiki pages are immediately online when modified and it looks like you currently cannot be notified when someone changes them.
The link to the corresponding readthedocs section could also be added in the Contribution guide cppTango github wiki page?

[Ingvord]

The advantage of having it on readthedocs is that again, we can discuss/review the documentation before it is online via Pull Requests.

OK, I see the point. Still I think it is an over kill. This thing is interested only for a very limited number of people, who can discuss it online (teleconf) and It won't change much over time. Changes, if any, are only interested again for a very limited group of people and can be announced via email.

Anyway, if you eager to keep it in read-the-docs, maybe it is better to create a dedicated section "Maintainers guide"

[Ingvord]

And we need to add upgrading Docker (tango-cs,tango-db) task

[cmft]

Hi @Ingvord and @bourtemb,
Should be nice it we could have a branch in TangoSourceDistribution for testing the prerelease.

[Ingvord]

@cmft we have it! https://github.com/tango-controls/TangoSourceDistribution/tree/prepare-9.3.3

There is corresponding PR based on that branch as well: tango-controls/TangoSourceDistribution#18

[cmft]

Thanks @Ingvord i did not see it

[bourtemb]

I added all the files (40 files) generated by appveyor to the 9.3.3 github release so we won't lose them after 6 months.

[t-b]

Closing in favour of #594. Please reopen if you disagree.