search

coin3d / coin

Coin3D core library
BSD 3-Clause "New" or "Revised" License
281 stars 106 forks source link

Create releases for Coin and all subsequent Gui Toolkits #180

Closed VolkerEnderlein closed 9 months ago

VolkerEnderlein commented 4 years ago

Original report by Volker Enderlein (Bitbucket: VolkerEnderlein, GitHub: VolkerEnderlein).

As the CMake stuff matures and the CI is in place and working we should force ourselves to make a release for Coin 4.0 and all the SoGui-Toolkits. Other repositories may release later (I am thinking as of SimVoleon and Sc21). This should be done before making the transition to Git/Github.

This issue should hold the necessary information and steps that need to be performed.

First things that come to mind are the update on the documentation and repository structure. When talking about the repository structure I mean that we don’t need MSVC related parts of the build directory anymore as they can easily be generated with the CMake scripts. Documentation updates are needed for the INSTALL, README, … files. Especially the build instructions need to be updated (or at least synchronized with the Wiki pages).

Feel free to add other related tasks.

VolkerEnderlein commented 4 years ago

Original comment by Giampiero Gabbiani (Bitbucket: ggabbiani, GitHub: ggabbiani).

I would add the examples too and exclude SoGtk as in the following:

‌

‌

Regards

Giampiero

VolkerEnderlein commented 4 years ago

Original comment by Volker Enderlein (Bitbucket: VolkerEnderlein, GitHub: VolkerEnderlein).

Full ACK, Giampiero.

What naming scheme would you suggest for the AppVeyor CI to not conflict with the releases?

Up to now we are using coin-4.0.0-src.zip and coin-4.0.0-msvc16-x86.zip for example. Should we add a -latest to this name to better show its a frequently updated package? Or should I include the abbreviated commit hash value? I avoided that, because the storage for free projects is limited to a mere 1GB of data and every CI build would use at least 200 MB of it.

BTW. nice scheme :grinning:

Cheers, Volker

VolkerEnderlein commented 4 years ago

Original comment by Giampiero Gabbiani (Bitbucket: ggabbiani, GitHub: ggabbiani).

Hi Volker ,

the scheme you adopted is fine for me, I’m plying with azure / docker integration , the idea is to produce Docker ‘builder’ images on DockerHUB - one for each Coin3D project - tagged with the target OS. It is similar to what implemented on BB pipelines but with a better and more complete platform coverage.

So yes, I would not use the commit hash since our space could be exhausted very quickly … my vote is for the -latest !

A possible compromise could be to reduce granularity to major.minor version only for both sources and binaries, eventually postfixed by .latest|-latest. In that case your examples would become:

coin-4.0{.latest}-src.zip

coin-4.0{.latest}-msvc16-x86.zip

The rest being possible to be retrieved from the source repo history and tags.

One final consideration about the storage: why do not try to use a different storage provider for the artefacts only? Google drive gives 15GB for free …

Regards, Giampiero

veelo commented 4 years ago

Thank you for doing the releases, @VolkerEnderlein. Great job!

VolkerEnderlein commented 4 years ago

Thanks @veelo I just added the missing tar.gz sourceballs. One question remains: I simply copied the *.zip files from the Bitbucket server to preserve the SHA/MD5 check sums. But the zipfiles still contain Mercurial version control information. What do you think, should I remove the version control information and therefore change the SHA/MD5 check sums as the consumers need to update the path to the sources anyway or just keep it as it is?

veelo commented 4 years ago

My opinion is of little relevance, I think packagers may have a better answer. But I'd not expect any version control information in a zip archive. If I understand correctly: the version stays the same because the source code has not changed, yet if github generates the archives instead of bitbucket the check sums change, which may confuse distributions. I would not worry about that too much, and probably go with whatever was easiest for me...

rickertm commented 4 years ago

Is there any chance of a new patch release tag for Coin, simage, SoQt etc. given the many important changes in the past few weeks? This would definitely help in packaging, as some distributions or package managers only accept tagged versions without custom patches.

See also https://github.com/coin3d/soqt/issues/54

VolkerEnderlein commented 4 years ago

Sure we could do, now that the CI is fully functional again. But I would like to get a solution for issue #379 into this version. This is really a blocker for some of us. What version number would you suggest for Coin? 4.1.0 or 4.0.1? If we consider it a patch release I would vote for a 4.0.1.

rickertm commented 4 years ago

An update of the patch version, i.e., Coin 4.0.1, simage 1.8.1, SoQt 1.6.1 etc. would be fine for me. The new source archives with all submodules integrated also help a lot.

rickertm commented 4 years ago

Now that the issue has been closed it seems like a good time for new version tags? If there are further issues, these can always be resolved in a later patch release.