On 6 September 2016 at 12:18, Ian Dunlop <[email protected]> wrote:
> Need some guidance on a some of the things in https://cwiki.apache.org/confluence/display/TAVERNADEV/2016-03+Taverna+Graduation+Maturity+Assessment Yes, I think it's good we do ask abut the assessment questions bit by bit like this - Shoaib asked me similar things in the office. I guess we could end up with quite a few emails though.. but that's probably good for the record! > eg > RE10: Releases consist of source code, distributed using standard and open > archive formats that are expected to stay readable in the long term. [6] > Apache Taverna is based on open source, community maintained languages > (list needed - Java, Android). > > Anyone done a count of all the languages? I'll have a go.. Java (including Android), Ruby on Rails, JavaScript, Bash There's some older Ruby and Python stuff hanging around at https://github.com/mygrid which we didn't move to Apache. But I think RE10 talks about the form and distribution of the release archives - not which language it uses. So I guess the real answer is more something like Releases at https://archive.apache.org/dist/incubator/taverna/source/ are replicated to the standard Apache mirrors - https://www.apache.org/dyn/closer.cgi/incubator/taverna/source/ - archived as regular ZIP files. Not sure if ZIP is a 'standard and open' format as it's really a commercial format. However I don't think we would be required to also provide tar.gz - but that justification is used by some Apache projects to do dual formats. *Edit*: Yes it is.. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=60101 - https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT (Also they are presumably valid JAR files - so any Java installation should be able to unpack them with "jar x") > QU40: The project puts a high priority on backwards compatibility and aims > to document any incompatible changes and provide tools and documentation to > help users transition to new features. > Apache Taverna ... > > Backwards compatibility of what? Uh.. Yes I guess we have many challenges here. User-wise we can say that we provide backward compatibility by opening legacy Taverna 2 workflows as part of Taverna Language. The SCUFL2 workflow format also has features to support backwards compatibility, e.g. JSON schemas for activity configurations. Developer-wise we can say we use API/impl splits, semantic versioning http://semver.org/ and OSGi - we also provide developer upgrade documentation such as https://cwiki.apache.org/confluence/display/TAVERNADEV/Tutorial%3A+Move+a+plugin+from+Taverna+2+to+Taverna+3 I guess providing good change logs is also important - we only have two releases of the same component since moving to ASF - with Taverna Language 0.15.0 and 0.15.1, where we included a change log: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333250&projectId=12318322 -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718
