After a bit of offline discussion, I'm hesitantly ok with this, at least
enough to try. I can't deny that it would make my life easier if
reconfigure didn't automatically enforce a full java rebuild.
The release file at the root of linked images does contain a comment
with a timestamp, so ther
On 2016-12-02 09:24, Erik Joelsson wrote:
I don't think removing the time stamp is such a good idea. Then there
is nothing in the version string to tell my builds apart.
What kind of builds are you trying to tell apart? Different builds from
the same configuration will right now have the same
On 2016-12-02 02:47, David Holmes wrote:
On 2/12/2016 8:39 AM, Magnus Ihse Bursie wrote:
Our current default is to create a version-opt string on the format
'..' during configure.
The problem with this is that each time the configure script has change,
a reconfigure is triggered. This will crea
I don't think removing the time stamp is such a good idea. Then there is
nothing in the version string to tell my builds apart.
/Erik
On 2016-12-01 23:39, Magnus Ihse Bursie wrote:
Our current default is to create a version-opt string on the format
'..' during configure.
The problem with th
On 2/12/2016 8:39 AM, Magnus Ihse Bursie wrote:
Our current default is to create a version-opt string on the format
'..' during configure.
The problem with this is that each time the configure script has change,
a reconfigure is triggered. This will create a new version-opt, and
hence a new vers
Our current default is to create a version-opt string on the format
'..' during configure.
The problem with this is that each time the configure script has change,
a reconfigure is triggered. This will create a new version-opt, and
hence a new version string. This in turn will trigger a rebuil
