ddekany commented on PR #103: URL: https://github.com/apache/freemarker/pull/103#issuecomment-1869175605
> Ok thanks. I discovered one problem: The tokens like `nightly_@timestampInVersion@` in comments of `version.properties` were replaced too (I think in [FreemarkerRootPlugin](https://github.com/apache/freemarker/blob/2.3-gae/buildSrc/src/main/kotlin/freemarker/build/FreemarkerRootPlugin.kt#L67C56-L67C56) ). I think that this can easily be forgotten during a release. Thus I changed the comment in [9677cda](https://github.com/apache/freemarker/commit/9677cdafe783ee46d87a98fd585b939b0b6f50b2) slightly to `nightly_[timestampInVersion]` (square brackets `[]` instead of `@@`). Now that that the timestamp causes complications, we should just change the convention to `version=2.3.33-nightly`. Pretty much nobody cares about the build timestamp of a snapshot version after all. (Of course it would be also possible to set the `filter` so that it doesn't replace in comment lines, but that would just adds even more complication.) > [c9aa766](https://github.com/apache/freemarker/commit/c9aa766978359232410aabb8808c3b1e2faa182a) : I decided to NOT remove the `buildTimestamp` for now, because removal made some testcases fail and the buildtimestamp is also referenced in code (Version.java). I wanted to avoid too many changes for this PR here for now, before having a discussion about it. I say, we just keep it in the `Version` API, but mark it as deprecated, and always return `null`. (It was documented that it can return `null`, and it's quite unlikely that anyone even calls that method, and also fails on `null`.) That's the price of reproducible builds. The JUnit tests has to be adjusted for this. And all these change belongs to this PR of course. > `After 3 years of work on Reproducible Builds, it has been found more useful as an internal file format: Reproducible Central and its .buildspec format is more what we need to check that Reproducible Builds results has been achieved. .buildinfo just records a build, be it reproducible or not. ` > > So I don't really know how to proceed. My gut feeling is that we could keep it like it is now. We could just explain e.g. in the README which JDK you need for a reproducible build (and make a recommendation) and then it is up to the developer bringing it's machine to this state. Ironically, we did have the exact JDK version in the META-INF of `freemarker.jar`, but now that was removed because of reproducible builds, which makes it harder to actually reproduce the build for someone else. Anyway... We could put this information automatically into the source artifact (that one we publish to Maven Central, and also into the source release), and the we can tell people to look for the information there, if they need to reproduce the build, and it didn't match at first attempt. > > `gradlew build`, and then see in `build/distributions`. > > Oh, so simple.. Thanks :) > > One thing I could not test: When I adjusted `version.properties` to `2.3.33` to simulate a release, `gradlew clean build` and `gradlew clean check` failed with > > ``` > Execution failed for task ':verifyReleaseSetup'. > > Package signing is disabled! Yeah, releases must be signed. (If you have `gpg` installed anyway, that's the easiest.) Please check the included `gradle.properties` to set that up. (Also I add pointers for building distribution artifacts into the README.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
