-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue #24284 Fixed git.build.time #24316
Conversation
dmatej
commented
Feb 24, 2023
- Fixes comment in Looks like the glassfish 7.0.1 release artifact contains the 7.0.0 version info #24284
- was overriden by a value from eclipse project 1.0.8
- was overriden by a value from eclipse project 1.0.8 Signed-off-by: David Matějček <[email protected]>
I'd rather have ever-changing IMO - the timestamp in signature file is enough.
|
I have yet another changes prepared, but I wanted to push this first before somebody starts screaming that I did too many changes again :D (revisited branding.properties, related documentation and implementation) Also - the commit is useful when you start arguing what was the source commit of the build. That's what I did in my next PR (yet after one with plugin updates). I don't understand the reason for eclipse-ee4j/ee4j#71 - it doesn't make builds reproducible at all. I think it should work exactly opposite - to be able to run the build with -Dproject.build.outputTimestamp with one concrete time stamp for several executions, but this change made it mandatory. |
But maybe we could even abandon the build id and rather replace it with more readable information instead of generating "magical" id:
Then in the log output instead of this: (My usual issue - do I work with snapshot or with a released version? How old is it?) The current versioning and build id idea comes yet from SGES2/SJAS9, which used SVN and I have found also some old test for things which were already removed. |
This would leave other I'm all for only-commit (full hash) (and no timestamp). |
👍 |