| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Minor issues building base 7.0.4 on Windows |
| From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Engbretson, Mark S." <engbretson at anl.gov> |
| Cc: | 'tech-talk' <tech-talk at aps.anl.gov> |
| Date: | Wed, 4 May 2022 11:14:28 -0700 |
On 6/1/20 18:21, Michael Davidsaver wrote:
On 6/1/20 5:48 PM, Engbretson, Mark S. wrote:Can't you keep both revision and date? Knowing that something was compiled 2 years ago means much more to me than a revision number which is meaningless to me unless i actually know what the current release is. Unless this test was performed at run time and told me how far out of sync this was with the master branch.A revision is useful to me when it shows up here on tech-talk along with a request for help. Also, recent GCC complains about use of __DATE__ wrt. https://reproducible-builds.org/ (which I agree with)
Digging up an old thread... I've added a codeathon project idea of capturing a VCS commit date in addition to the revision/hash. The commit date is reproducible, while adding some context to the numeric/symbolic rev. https://github.com/epics-base/epics-base/wiki/Codeathon-project-ideas#genversionheaderpl-emit-commit-date