I think it is quite important to have a high level list of features associated with each release. I'm not prsenting the gory detail of what doesn't work but trying to present and accurate picture of what does. Everyone can then see what is in a release. So to the "does it go in RELEASE_NOTES?" question. I am proposing we take the high level feature bullet points and add something along the lines of.
Features ======= - A clear set of SPIs intended to be stable over future releases -- core-spi -- assembly -- interface -- ??? - Extensions now loaded via Java service mechanism -- Refactored extensions to use new SPIs (see below) - Improved Package/Class naming consistency across modules - New assembly model implementation taking into account SCA 1.0 artifacts -- Data duplication between assembly model and runtime reduced - Simple single process domain support -- Contributions support to scope items being deployed into the runtime - Maven and Ant base sample builds in the binary distribution - Support for all of Java Annotations and API Specification V1.0 apart from -- ??? - Implementation Extensions -- Java -- Script supporting (Ruby, Python, Groovy, JavaScript) - Binding Extensions -- Axis2 -- RMI -- JSONRPC -Databinding Extensions -- Axiom -- JAXB -- SDO - Hosting Extension -- Embedded -- Tomcat -- Jetty -- RMI Do you think that is too much? This is the kind of thing I actively look for in a release notes. I.e I want to know what's changed. However I do see your point about cluttering the RELEASE_NOTES so how about we instigate a CHANGES file and put this info there. I would also like to see the information somewhere up on the web site so I'll try and work that in when we get to the point of putting the release artifacts up. Simon
