Hi Dan! 0.2 is ok with me too. That depends what else is planed before a 1.0 release. If there will be not many API changes between the current release and the planed 1.0 status, then 0.9.something would just better reflect this. But at the end of the day it's mostly about user expectations and numbers are secundary. So let's stick with 0.2
I'll just like to get a release done finally because that's what users can take and pick up from repository.apache.org and Apache maven central. That's just better to promote than any temporary snapshot ;) The only javax.* dependency I found was the one for the servlet spec. I'll fix that. LieGrue, strub --- On Sat, 4/23/11, Dan Haywood <[email protected]> wrote: From: Dan Haywood <[email protected]> Subject: Re: thinking about a release To: [email protected] Cc: "Robert Matthews" <[email protected]> Date: Saturday, April 23, 2011, 10:45 AM Hi all, Yes, I have just been wanting to chip away at the documentation - as the various commits will attest. Also, I can see both Rob and Kevin are steadily making improvements, so there's ongoing work there, so didn't want to unnecessarily break the flow. But I'm happy to put together a release if that's what people want. What I propose is: 1. I'll just finish the core docs (should be done in next days or two) 2. make sure that the copyright and other stuff is ok for the remaining modules 3. update the JIRAs so capture the fact that documentation for some of the other modules is not complete (most notably, we only have a placeholder for the default runtime [oai.runtimes:dflt] module). 4. I'll check-in with Rob and Kevin to make sure that we choose a suitable point to take the tag. Then I'll start looking into what makes up a release. In terms of Mark's questions: 1.) re-check the IP clearance. Especially our 3rd party dependencies. Even an incubator release must meet our license requirements. E.g. use specs from http://repo1.maven.org/maven2/org/apache/geronimo/specs/ instead of any javax.* or org.hibernate.* maven artifacts. We won't have dependencies on org.hibernate, but we might be depending on some javax. stuff. They should all be in isis-parent pom.xml, so perhaps someone could take a look? 2.) We better not need any 3rd party <repositories>. If we have such a thing, then we should look if there are any alternatives. That's no hard show stopper but generally a good idea to look at We do have a dependency in the restful view on JBoss, but that stuff is all Apache license v2. 3.) Go through all open jira issues and identify show stopper issues. I don't think there are any, but I'll check. 4.) create a new isis-0.9.0 'Version' in Jira and move all bugs to 'fixed in isis-0.9.0' in Jira. I've been working on 0.1.2-SNAPSHOT, but I can rename to 0.9.0 if you recommend it. I do actually have 0.2.0 and 0.3.0 releases planned with some tickets assigned to them, but they can easily be renamed too if required. Cheers Dan ~~~~~ On 22/04/2011 14:26, Kevin Meyer - KMZ wrote: Hi Mark, I get the impression that most of (Dan's) hesistation has been about the documentation.. we don't want to lose potential interest because of this.. Having said that, what do the people who have joined more recently have to say? Sabine, Michael, Vangjel, etc? Kevin On 22 Apr 2011 at 9:56, Mark Struberg wrote: Hi folks! I peaked over the sources a little bit (still don't have much clue) and it doesn't look that bad imo. What about thinking off a new isis 0.9.0-incubating release? We did this 0.9 version scheme in a few other projects which are already close to 1.0 to show it's not _yet_ 1.0 but already quite near. The fact that we have a incubator release out there is pretty important for the adoption rate sometimes. WDYT? This of course will need a bit of preparation: 1.) re-check the IP clearance. Especially our 3rd party dependencies. Even an incubator release must meet our license requirements. E.g. use specs from http://repo1.maven.org/maven2/org/apache/geronimo/specs/ instead of any javax.* or org.hibernate.* maven artifacts if possible. 2.) We better not need any 3rd party <repositories>. If we have such a thing, then we should look if there are any alternatives. That's no hard show stopper but generally a good idea to look at 3.) Go through all open jira issues and identify show stopper issues. 4.) create a new isis-0.9.0 'Version' in Jira and move all bugs to 'fixed in isis-0.9.0' in Jira. Anything I forgot? LieGrue, strub
