Call for Discussion: New Project: Developer's Guide -- suggestion to separate information having different life cycles

Joe Darcy joe.darcy at
Sat Mar 14 01:34:27 UTC 2020


Having penned a complementary "OpenJDK Developers' Guide" back in 2010 
[1], I wanted to offer a suggestion on structuring the new guide: 
separate information of different life cycles into different documents. 
For example, put any release-specific information into release-specific 
documents and put stable, mostly time-invariant information into the 
main developer's guide.

In the JDK code base, over the years we've recognized that hard-coded 
release values used in tests or the javadoc are often a maintenance 
burden. I think the same would be true of a developer's guide; the guide 
shouldn't necessarily need to be updated every six months (or three 
months) just because the feature releases have a six-month cadence and 
update releases come out every three months. [2]




This material was used to seed the CSR compatibility discussion years later:

[2] HT Prof. Edsger W. Dijkstra on describing the Buxton Index in his 
essay "The strengths of the academic enterprise" 
To rephrase the suggestion: avoid shear stress in the guide by not 
mixing content with different Buxton indexes.

More information about the discuss mailing list