Release info confusing/misleading

[seanmcleod]

@bcoconni @agodemar If I'm a random JSBSim user and not familiar with our CI setup the info you see on the Releases section can be confusing/misleading.

In particular it currently states:

bcoconni released this 19 days ago · 67 commits to master since this release 
JSBSim-trusty-v2018a 
 e5cc599 

So to me this implies that the release is built using code that is 67 commits behind the head of the master branch. Plus the hash listed on the left e5cc599 also doesn't refer to the latest commit to the head of the master branch.

I downloaded JSBSim.exe to confirm my understanding that it should match the latest commit based on our CI setup of pushing the latest build to the Release.

C:\Users\Sean\Downloads>.\JSBSim.exe

  JSBSim version 1.0.0 [build 179/commit 93f89276968a223aa0bc8e3e34fc9f32f70f1fd3] Jun 18 2018 15:26:06

  Usage: jsbsim [script file name] [output file names] <options>

And sure enough due to the very useful addition of the commit hash as part of the version info I can see that this executable has been built using the latest commit from yesterday, i.e. it isn't 67 commits behind the master branch.

If we don't want the misleading info does this mean we need to publish a new Release for every commit? And can this be automated as part of the CI process, with some complication I'm guessing in terms of coordinating the two CI builds?

[agodemar]

@seanmcleod I agree with you, that's a misleading piece of information. May be something along the line of this?

[seanmcleod]

I think for now we just need to have the Release info on the GitHub Release page make it clear that the binaries are based on the latest commit. Users can browse through the commit messages for now.

[seanmcleod]

For now I've added the following comment to the release notes.

Note - The assets listed above have been generated from the latest successful commit to the master branch, i.e. they are not from May 31 2018.

[Phillip-M-Feldman]

As far as I can tell, there's currently no well-defined version release of this package. There's one tagged commit on github from last May with no evidence that it was intended as a formal release (and certainly no version number), and there's a version 1.0.0.dev1 on PyPI which does not correspond to any tag in the
github repo and is explicitly not for general use (dev1).

[agodemar]

Greetings,
we, JSBSim main developers/users, definitely need and welcome any kind of help and support in the area of continuous deployment. We are volunteers...
Thanks in advance to anyone who will contribute to tune our CI workflow!

[Phillip-M-Feldman]

Does continuous deployment mean that there are no stable releases? Users need to know which versions are considered relatively stable and which are not. This is impossible with the current scheme.

…

On Wed, Jan 9, 2019 at 2:27 AM Agostino De Marco ***@***.***> wrote: Greetings, we, JSBSim main developers/users, definitely need and welcome, any kind of help and support in the area of continuous deploy. Thanks in advance to anyone who will contribute to tune our CI workflow! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#69 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABBBxO13PNF5ZWTbIfMS2wrkPI2jeXDtks5vBcQGgaJpZM4UtGz5> .

[seanmcleod]

@Phillip-M-Feldman correct we don't currently mark any particular commit as stable or have stable branches. Any commit that builds successfully and passes all the test cases is then uploaded to Releases as the current release.

I'm not really familiar with FlightGear's release mechanisms but they more than likely have a bunch of their own tests that have to pass before they include a particular JSBSim build into one of their releases.

[bcoconni]

I'm not really familiar with FlightGear's release mechanisms but they more than likely have a bunch of their own tests that have to pass before they include a particular JSBSim build into one of their releases.

JSBSim updates are pushed manually to FlightGear by myself 😉

New features are introduced in the development version before the feature freeze. FlightGear has its own CI which builds the executables as soon as a change is pushed (just as we do) and this allows volunteers to test the bleeding edge software.

Official releases happen once every quarter (2018.1, 2018.2, 2018.3, etc.) and bug fixes updates are released from time to time (2018.3.1, 2018.3.2, etc.). I took opportunity of these patch versions to release JSBSim bug fixes to FlightGear as well. Some details on the release plan are given on the FlightGear wiki.

[bcoconni]

@Phillip-M-Feldman

Does continuous deployment mean that there are no stable releases?

No it does not. As @seanmcleod mentioned, at the moment we are using Continuous Integration (CI) to have a rolling release but it is not incompatible with a stable release. CI can be tuned to automatically publish a stable release when, for example, a commit is tagged.

However the problem is not really at a technical level since our CI is already capable (with a bit of tuning) to release a stable version. It is rather that we, collectively, need to make a decision about when the code is good enough for a stable release.

Users need to know which versions are considered relatively stable and which are not.

You rightfully opened the issue #153 about this and I suggest to continue the discussion there.

[bcoconni]

A new release Rolling_Release_v2019 has been pushed following issue #166. However this will suffer from the same problem than the previous release, i.e. it claims that

bcoconni released this xx minutes ago · nn commit to 114173fdc42a25dd515596084b495e9976857eda since this release

[seanmcleod]

Yep, although I guess the period since release and the number of commits shown has at least been reset for now 😉

[bcoconni]

I have made some investigations recently about this particular issue. I think this is due to GitHub requesting to tag a commit when creating a release then using this tag as a reference to how old the release is with respect to the cutting edge code.

I am unsure if this issue can be properly worked around. At the moment, the options are:

• Tagging each commit (very ugly if you ask me)
• Moving the tag to HEAD at each commit but I think this would need to use the option --force when pushing each commit which is quite unusual and could break history with regard to all the repository clones.
• Simply display a warning message as we are currently doing.

[bcoconni]

🎉 JSBSim now has its first official release v1.1.0 🎉

You can download binaries from the v1.1.0 release on GitHub or install the Python packages with pip:

> pip install jsbsim

Enjoy !

If you encounter issues with the published binaries, please open a new issue.

For the record, version v1.0.0 has been skipped since its tentative release happened such a long time ago that the released version would have been too different from v1.0.0.dev1.

[Phillip-M-Feldman]

This is welcome news! (But, somewhat overdue).

…

On Sat, Oct 17, 2020 at 9:18 AM Bertrand Coconnier ***@***.***> wrote: Closed #69 <#69>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIEDRCULXDIVLHTC24GPF3SLG7UVANCNFSM4FFUNT4Q> .

[bcoconni]

@Phillip-M-Feldman Better late than never 😉

[bcoconni]

Just FYI with the recent updates I made to our GitHub workflow, deploying a new release is just a matter of tagging a commit:

> git tag v1.x.y
> git push origin v1.x.y

🎉 Et voilà ! 🎉

Our GitHub workflow will then automatically process the following steps:

1. Compile the executables and the Python modules
2. Test them
3. Create the packages (Debian for Ubuntu, Python wheels and the Windows installer)
4. Create a new release on GitHub Release v1.x.y (:warning: the version number is obtained from the file CMakeLists.txt, not from the tag name - see below ⚠️)
5. Upload all the files to the GitHub Release v1.x.y
6. Upload the Python wheel packages to our PyPI project page
7. Update the C++ API documentation

⚠️ Caution: check the version number in CMakeLists.txt before pushing the tag ⚠️

jsbsim/CMakeLists.txt

Lines 8 to 10 in 9a98d11

	set(PROJECT_VERSION_MAJOR "1")
	set(PROJECT_VERSION_MINOR "2")
	set(PROJECT_VERSION_PATCH "0.dev1")

If the version already exists when pushing the tag, PyPI will complain and the workflow will fail miserably. My suggestion to avoid this annoying situation is to bump the version number just after the tag has been pushed. That way, the CMakeLists.txt is ready for the next release.

Good practice is also branching the code before a new major version is released. Use the branch name release/v1.x. Minor releases are issued from the same major release branch (i.e. releases v1.1.1, v1.1.2, etc. will be issued from the branch release/v1.1)