> It is certainly truth that if Apache does only source releases, then it would be great if two subsequent builds on the same source result in the same bits.
I support reproducible builds. One simple rule here is to ignore everything from the build environment (date time, server name, build number, maybe even git info). Since only release-time versions matter we could hardcode/generate all these version strings and only update them as part of the release process. It would also be nice if we would reduce these atypical dependencies in our own codebase. I know there are some impl dependencies on PHP.editor in the PHP cluster which could perhaps become friends at least? Generally we are too strict with our APIs outside the platform. Nobody is really building products on top of the other clusters and they would not complain if we don't offer perfect compatibility. --emi vin., 2 aug. 2019, 14:05 Jaroslav Tulach <[email protected]> a scris: > > However, what would be the pros and cons or possibilities of making > > > implementation and specification versions the same? Given we already > > increment all specification versions between releases, this should > > achieve the same purpose for anyone not utilising daily builds? > > > > > http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-vers > > Implementation version is a free form text. Specification version must be > dewey decimal. Having them be the same means that implementation version > would be equal to dewey's decimal spec version. Could it work? Maybe. > > It is certainly truth that if Apache does only source releases, then it > would be great if two subsequent builds on the same source result in the > same bits. > -jt >
