Dear Radiance Community,
What makes a Radiance release "official"?
Looking at the Radiance Github site (https://github.com/NREL/Radiance/releases), I see that version 4.2.2 is the latest "official" release, whereas 5.0.a.1, 5.0.a.2 and 5.0.a.3 are pre-release versions.
What makes a Radiance release "official"? Is there a validation procedure carried out? If so, who is in charge of this and what are some of the test cases used for validation?
Thank you in advance,
Andrei Kolomenski
Hi Andrei,
My $0.02, as an outsider:
The NREL GitHub site is simply a place where we (NREL) post our installers. Perhaps unfortunately, GitHub expects the "official" and "pre-release" tags on all the releases hosted there. I follow the convention laid out by Greg Ward as far as what is the official release and what is pre-release code, and we name our installers based on this convention (where ".a" is alpha code, ".b" is beta, and the absence of a letter denotes "official" releases. To be clear, the NREL Radiance GitHub site is simply a mirror of the main Radiance code repository which is managed with CVS, is hosted by LBNL, and this is the official release page:
http://www.radiance-online.org/download-install/installation-information
As far as testing, there is no standard test protocol for builds or releases. I started some tests that can be run in the CMake framework, here:
https://github.com/NREL/Radiance/tree/combined/cmake_tests
A (long) while ago, (I believe it was) Georg Mischler (who) started an Scons-based test framework, that got about as far as mine did:
https://github.com/NREL/Radiance/tree/combined/test
My tests are stupid and fallible. Georg's tests are very old and test a lot of seldom-used stuff (and none of the new stuff like rcontrib or photon map). They are both in the source for what they're worth; people could build on either of these. I believe CMake's test framework (CTest) is awesome and could be used to build a very robust set of tests, and we would love to add these to the Radiance source and incorporate them into a dashboard, but this is unfortunately way down there, on a long TODO list.
- Rob
On 7/7/15, 2:34 PM, "Kolomenski, Andrei (JSC-SF311)[WYLE INTEG. SCI. & ENG.]" <[email protected]<mailto:[email protected]>> wrote:
Dear Radiance Community,
What makes a Radiance release "official"?
Looking at the Radiance Github site (https://github.com/NREL/Radiance/releases), I see that version 4.2.2 is the latest "official" release, whereas 5.0.a.1, 5.0.a.2 and 5.0.a.3 are pre-release versions.
What makes a Radiance release "official"? Is there a validation procedure carried out? If so, who is in charge of this and what are some of the test cases used for validation?
Thank you in advance,
Andrei Kolomenski
Hi Andrei,
Rob is right that there is no big difference between an "official" release and any other update. The main reason to have official releases is so individuals or institutions that distrust the development process can have a known quantity.
I typically create an official release every year or two when I feel: (a) there are enough new features to make a release sensible, and (b) the code is at a relatively stable point where nothing drastically new and untested has just been added. Nevertheless, most official releases are followed in the subsequent weeks with patch releases to fix bugs that we or others have identified in the code. It is really the patched official releases that end up being the most stable point, though it must be said at this time that the last official release is rather seriously behind in the features department.
Our goal is to make a new official release around the time of the upcoming Radiance workshop in August.
Cheers,
-Greg
From: "Guglielmetti, Robert" <[email protected]>
Subject: Re: [Radiance-general] Radiance "Official" Release
Date: July 7, 2015 2:38:18 PM PDTHi Andrei,
My $0.02, as an outsider:
The NREL GitHub site is simply a place where we (NREL) post our installers. Perhaps unfortunately, GitHub expects the "official" and "pre-release" tags on all the releases hosted there. I follow the convention laid out by Greg Ward as far as what is the official release and what is pre-release code, and we name our installers based on this convention (where ".a" is alpha code, ".b" is beta, and the absence of a letter denotes "official" releases. To be clear, the NREL Radiance GitHub site is simply a mirror of the main Radiance code repository which is managed with CVS, is hosted by LBNL, and this is the official release page:
http://www.radiance-online.org/download-install/installation-information
As far as testing, there is no standard test protocol for builds or releases. I started some tests that can be run in the CMake framework, here:
https://github.com/NREL/Radiance/tree/combined/cmake_tests
A (long) while ago, (I believe it was) Georg Mischler (who) started an Scons-based test framework, that got about as far as mine did:
https://github.com/NREL/Radiance/tree/combined/test
My tests are stupid and fallible. Georg's tests are very old and test a lot of seldom-used stuff (and none of the new stuff like rcontrib or photon map). They are both in the source for what they're worth; people could build on either of these. I believe CMake's test framework (CTest) is awesome and could be used to build a very robust set of tests, and we would love to add these to the Radiance source and incorporate them into a dashboard, but this is unfortunately way down there, on a long TODO list.
- Rob
On 7/7/15, 2:34 PM, "Kolomenski, Andrei (JSC-SF311)[WYLE INTEG. SCI. & ENG.]" <[email protected]<mailto:[email protected]>> wrote:
Dear Radiance Community,
What makes a Radiance release "official"?
Looking at the Radiance Github site (https://github.com/NREL/Radiance/releases\), I see that version 4.2.2 is the latest "official" release, whereas 5.0.a.1, 5.0.a.2 and 5.0.a.3 are pre-release versions.
What makes a Radiance release "official"? Is there a validation procedure carried out? If so, who is in charge of this and what are some of the test cases used for validation?
Thank you in advance,
Andrei Kolomenski
Hello Rob & Greg,
Thank you for the responses and clarification.
As I understand, community testing/debugging is the main way of validating a Radiance release. It certainly would be nice to have a standard validation procedure (maybe using CMake/CTest) for each Radiance release.
Kind Regards,
Andrei Kolomenski
-----Original Message-----
From: Greg Ward [mailto:[email protected]]
Sent: Tuesday, July 07, 2015 6:05 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] Radiance "Official" Release
Hi Andrei,
Rob is right that there is no big difference between an "official" release and any other update. The main reason to have official releases is so individuals or institutions that distrust the development process can have a known quantity.
I typically create an official release every year or two when I feel: (a) there are enough new features to make a release sensible, and (b) the code is at a relatively stable point where nothing drastically new and untested has just been added. Nevertheless, most official releases are followed in the subsequent weeks with patch releases to fix bugs that we or others have identified in the code. It is really the patched official releases that end up being the most stable point, though it must be said at this time that the last official release is rather seriously behind in the features department.
Our goal is to make a new official release around the time of the upcoming Radiance workshop in August.
Cheers,
-Greg
From: "Guglielmetti, Robert" <[email protected]>
Subject: Re: [Radiance-general] Radiance "Official" Release
Date: July 7, 2015 2:38:18 PM PDTHi Andrei,
My $0.02, as an outsider:
The NREL GitHub site is simply a place where we (NREL) post our installers. Perhaps unfortunately, GitHub expects the "official" and "pre-release" tags on all the releases hosted there. I follow the convention laid out by Greg Ward as far as what is the official release and what is pre-release code, and we name our installers based on this convention (where ".a" is alpha code, ".b" is beta, and the absence of a letter denotes "official" releases. To be clear, the NREL Radiance GitHub site is simply a mirror of the main Radiance code repository which is managed with CVS, is hosted by LBNL, and this is the official release page:
http://www.radiance-online.org/download-install/installation-information
As far as testing, there is no standard test protocol for builds or releases. I started some tests that can be run in the CMake framework, here:
https://github.com/NREL/Radiance/tree/combined/cmake_tests
A (long) while ago, (I believe it was) Georg Mischler (who) started an Scons-based test framework, that got about as far as mine did:
https://github.com/NREL/Radiance/tree/combined/test
My tests are stupid and fallible. Georg's tests are very old and test a lot of seldom-used stuff (and none of the new stuff like rcontrib or photon map). They are both in the source for what they're worth; people could build on either of these. I believe CMake's test framework (CTest) is awesome and could be used to build a very robust set of tests, and we would love to add these to the Radiance source and incorporate them into a dashboard, but this is unfortunately way down there, on a long TODO list.
- Rob
On 7/7/15, 2:34 PM, "Kolomenski, Andrei (JSC-SF311)[WYLE INTEG. SCI. & ENG.]" <[email protected]<mailto:[email protected]>> wrote:
Dear Radiance Community,
What makes a Radiance release "official"?
Looking at the Radiance Github site (https://github.com/NREL/Radiance/releases\), I see that version 4.2.2 is the latest "official" release, whereas 5.0.a.1, 5.0.a.2 and 5.0.a.3 are pre-release versions.
What makes a Radiance release "official"? Is there a validation procedure carried out? If so, who is in charge of this and what are some of the test cases used for validation?
Thank you in advance,
Andrei Kolomenski
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general