Re: [boost] [release] Continuous release archives.

On Tue, Aug 9, 2016 at 7:17 AM, Tom Kent wrote:

On Tue, Aug 9, 2016 at 3:16 AM, Niall Douglas wrote:

...

On 7 Aug 2016 at 20:42, Rene Rivera wrote:

...

Please report any problems sooner rather than later. So that we can try and address them before it's took late.

Firstly thank you for making this happen. Thanks for this kind of work is insufficiently given at Boost.

...

[1] <https://sourceforge.net/projects/boost/files/boost/ snapshots/master/> [2] https://bintray.com/boostorg/master/snapshot#files

I appreciate that both URLs have "snapshot" in their name, but I am uncomfortable with the way the filename is named as if it is a release. I think this will lead to people getting confused that a snapshot archive which may be very buggy is a release archive. That will undoubtedly lead to bug reports here for a "release" which never happened.

Can you build into the archive name something like this pattern: boost_1_62_0_snapshot_201608090906.zip?

This seems like a great idea to me. I agree that the current pattern may lead to confusion.

I was originally doing something like that.. Unfortunately the way that the uploads work for both Bintray and SF make doing that extremely difficult. In particular it's the deleting of anything but the newest archives that is difficult to achieve with their respective automated upload facilities. That said.. I say lets try it the way it is for at least one release and depending on the fallback we can try and find a way to have the tagged names.

I would also advocate spamming "snapshot" into various files in the

...

distro e.g. docs, release notes etc.

I disagree that the docs contained should be changed. Aside from the archive name, the contents should match bit-for-bit with what will eventually be released.

Indeed.. The intent is for them to match bit-for-bit. As it makes the release process much easier to just be able to rename one of the snapshots as beta or release and publish it in the non-snapshot location. The less manual work the release managers need to do, the more they can concentrate on other issues. And the faster the releases can happen. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail