[release] Continuous release archives.
Starting with this release the archives for the prospective beta and release candidates are continuously built from the master branch and uploaded to SourceForge [1] (and to Bintray [2]). The release team would really appreciate if authors would download the archives and check the contents. In particular that the archives contain all the content you expect of your library, or libraries. And if you can also try building in your system that would stupendous. The more eyes we have on the final release products the smoother the process will be. And result in more time that the master branch is not blocked. Please report any problems sooner rather than later. So that we can try and address them before it's took late. Thank you, The Release Team [1] <https://sourceforge.net/projects/boost/files/boost/snapshots/master/> [2] <https://bintray.com/boostorg/master/snapshot#files> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
The following libraries fail to build under Cygwin64: - Context - Fiber - Interprocess - Log Thomas
boost.context does not support cygwin yet. boost-coroutine(2) + boost.fiber will fail. 2016-08-08 12:24 GMT+02:00 Thomas Trummer <th.trummer@gmail.com>:
The following libraries fail to build under Cygwin64:
- Context - Fiber - Interprocess - Log
Thomas
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
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? I would also advocate spamming "snapshot" into various files in the distro e.g. docs, release notes etc. Finally, there is a small bug at least with the .7z distro, you are including the CI config files for appveyor and circleci, but are missing any files starting with a '.'. For completeness the latter should probably be included. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Aug 9, 2016 at 3:16 AM, Niall Douglas <s_sourceforge@nedprod.com> 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 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. Tom
On Tue, Aug 9, 2016 at 7:17 AM, Tom Kent <lists@teeks99.com> wrote:
On Tue, Aug 9, 2016 at 3:16 AM, Niall Douglas <s_sourceforge@nedprod.com> 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
On Tue, Aug 9, 2016 at 3:16 AM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
Finally, there is a small bug at least with the .7z distro, you are including the CI config files for appveyor and circleci, but are missing any files starting with a '.'. For completeness the latter should probably be included.
Hm.. It might be difficult to include the dot files.. But yeah, we should either include them or not include the other CI related files. And now that I think about it.. It would be rather easy to remove the CI files entirely. Thanks for pointing this out :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Tue, Aug 9, 2016 at 8:33 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Tue, Aug 9, 2016 at 3:16 AM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
Finally, there is a small bug at least with the .7z distro, you are including the CI config files for appveyor and circleci, but are missing any files starting with a '.'. For completeness the latter should probably be included.
Hm.. It might be difficult to include the dot files.. But yeah, we should either include them or not include the other CI related files. And now that I think about it.. It would be rather easy to remove the CI files entirely.
Thanks for pointing this out :-)
OK, I've made the change that removes the extra CI files. New archives will not contain them.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
participants (5)
-
Niall Douglas -
Oliver Kowalke -
Rene Rivera -
Thomas Trummer -
Tom Kent