Release assets for latest and greatest?

[seanmcleod70]

So currently when we release an official release/version like 1.2.2 it's assets are available via - https://github.com/JSBSim-Team/jsbsim/releases plus the Python module is uploaded to PyPi etc.

I'm just wondering whether in addition to the official releases that come out typically a couple of months apart whether we shouldn't also always make available a set of assets for the latest and greatest, i.e. the head of the master branch.

That way users like @Dobid wouldn't have to manually build the Python module in-between official releases - #1281 in order to get hold of the changes related to random seeds.

Or for example to get hold of the new Python type hinting without having to install lark while waiting for an official release.

[agodemar]

@seanmcleod70 I agree.
I had problems in building the Python module from the latest sources in my Anaconda environment. I then decided to conda install the latest version of JSBSim available on conda-forge channel.
I think it's the case to add a specific section in the documentation, as specific as possible, on how to setup the tools to build the Python module. For instance, a common case is: Windows users, not much experienced with Python tools and distributions.

[bcoconni]

Maybe another option is to follow the release early and often principle ? We are currently pushing the button every year or so. I see no reason why we couldn't do it more often.

I know traditionally I'm the one pushing the button but do not hesitate to ask for a release if you feel the need. We tend to be quite conservative in the changes we are making so our code is very stable. I cannot remember of a change that has broken the code in the last years so, at least theoretically, we could release at any time.

There is only one caveat which is that it is currently the branch release/v1.2 that is used for releases. At the moment, this branch has the same content as master except for the logging feature that I'd like to complete before including it in the released code.

[seanmcleod70]

Yep, I was thinking that we could release say 2-4 times a year with the push to PyPi etc. as part of the release.

But that in addition having the assets, Python wheel etc. available/kept around for the latest commit would make it easier for users, particularly Python users who possibly aren't regular C++ users used to building using CMake and then following the specific instructions on how to build the Python module etc,

[bcoconni]

But that in addition having the assets, Python wheel etc. available/kept around for the latest commit would make it easier for users, particularly Python users who possibly aren't regular C++ users used to building using CMake and then following the specific instructions on how to build the Python module etc,

We used to do that but I have removed that feature a bit more than 2 years ago (commit 0d26057 - Skip the build of Python wheels for "regular" builds to save time on the execution of the workflow.) because:

• Building the Python wheels is very long (approximately 20 minutes - see this job for instance)
• The job Python-Wheels is producing a lot of wheels which tend to clutter the Rolling Release although I am cleaning it up from time to time to keep the size of our repo reasonable (we've never been yelled at by GitHub but we are supposed to maintain the size of the repo below 1Gb or so).
• The Rolling Release is at the bottom of all releases so it is not that easy to find although this can be addressed by adding a link in the README.

[bcoconni]

Speaking about Release early and often, I've just updated the branch release/v1.2 to the latest and greatest (but the logging feature). This is including the PR #1291.

The release button can be pushed at any time. Let me know if you are OK with releasing v1.2.3 ?

[seanmcleod70]

All good from my side in terms of you releasing v1.2.3.