On 11/17/2010 04:35, Marshall Schor wrote: > > > On 11/16/2010 3:06 AM, Thilo Götz wrote: >> On 11/15/2010 23:31, Marshall Schor wrote: >>> >>> On 11/15/2010 8:26 AM, Thilo Götz wrote: >>>> On 11/15/2010 13:43, Marshall Schor wrote: >>>>> This is the release vote for uimaj sdk. It includes the release of the >>>>> build >>>>> tooling, and also the Eclipse update site. >>>>> >>>>> This is the first release as a TLP; the issues fixed include removing the >>>>> incubator - related disclaimers, etc. >>>>> >>>>> The list of issues fixed is here: >>>>> >>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315344&styleName=Text&projectId=12310570&Create=Create >>>>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315344&styleName=Text&projectId=12310570&Create=Create> >>>>> >>>>> and >>>>> >>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315481&styleName=Text&projectId=12310570&Create=Create >>>>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315481&styleName=Text&projectId=12310570&Create=Create> >>>>> >>>>> The artifacts being released (except the eclipse-update-site) are in the >>>>> Apache >>>>> Nexus staging repository, here: >>>>> >>>>> https://repository.apache.org/content/repositories/orgapacheuima-050/. >>>>> >>>>> The eclipse-update-site is here: >>>>> http://people.apache.org/~schor/uima-release-candidates/2.3.1-RC1/eclipse-update-site >>>>> <http://people.apache.org/%7Eschor/uima-release-candidates/2.3.1-RC1/eclipse-update-site/> >>>>> >>>>> The SVN tags for the things being released is: >>>>> >>>>> Build Tools: https://svn.apache.org/repos/asf/uima/build/tags/parent-pom-1 >>>>> UIMA-sdk: >>>>> https://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-distr-2.3.1-rc4 >>>> So how do I know these two go together? How can I know a >>>> couple of years from now that when I extract the 2.3.1 >>>> tag, I need to get the parent-pom-1 build tools to go with >>>> it? >>>> >>> Here's how: >>> >>> First of all, a few years from now, I think you won't have to do anything >>> special. >>> When you extract the 2.3.1 tag, it should just build. Here's the details. >>> >>> The 2.3.1 tag has poms which, in turn, specify the version 1 of the >>> parent-pom. >>> >>> That parent pom, assuming we pass the release, will be forever in Maven >>> central. >>> In particular the version 1 of that will be forever there. >>> >>> So, the indication of what the parent pom is needed, is indicated directly >>> in >>> the 2.3.1 poms. >>> >>> Is that sufficient, or have I overlooked something? >> Maybe I want to look at the source of the build tools because I suspect >> there's >> a problem. Or a later version of maven creates a problem where none has >> been. >> >> I assume I can go and look in some pom somewhere and find the version of >> the build tools I'm depending on, and extract the corresponding tag if I >> like? > > Yes, following the convention where when a release happens, we re-tag the > release candidate to be the same name, but without the -RC3 or whatever. > Or, if we don't do that, I guess you could look at the latest release > candidate. > > In our previous releases, I noticed that some release managers retagged things > and others didn't. But I think it's a good idea to do this. > > The "-1" part of parent-pom-1 is the "version" number. > > The other place you can get the source for the build artifact is from Maven > Central. When an artifact is released, it includes "attached" additional > things, one of which is the xxx-source-release.zip file. This is an > Apache/Maven standard which is supposed to be downloadable, and when unzipped, > include everything you need to rebuild the artifact from source. It's not > SVN, > though.
Which defeats the purpose. > > >> I admit I stopped paying attention to the build issues. Why can't the build >> tools have the same version number as the release? Just out of curiosity, >> since >> "parent-pom-1" does not seem a very expressive version number to me. > > The main reason for this is that the build tools are supposed to be reused for > multiple releases of things. For instance, the common Apache Parent POM is at > release "7" and is supposed to be used by Apache projects built with Maven > that > are trying to follow the Apache conventions. > > I was thinking ahead and imagining some release cycle where the components > might > be released separately, that might look like: > > (time ---> >>>) > 2.3.1 uimaj > 2.3.1 uima-as > 2.3.1 DictionaryAnnotator > 2.3.1 Regex Annotator > ... etc > > 2.3.2 DictionaryAnnotator (releasing an update to just one > annotator would be possible) > ... > 2.3.2 uima-as (releasing an update to uima-as without > changing the base would be possible) > 2.3.3 uima-as > > parent-pom-2 (releasing the parent-pom would only > need to be done when it changed) > 2.3.2 uimaj > 2.3.4 uima-as > > etc. > > Of course, whether or not to keep our versions all locked together is a > debatable decision. But I was planning for a future where we might want the > flexibility of releasing things separately. I just noticed that those version numbers now show up in Jira, and fill up the drop down. That does not seem desirable. Ok now I'm totally confused. I was going to open an issue to fix the batch scripts, see the users list. What are unreleased versions 2.2C and 2.3CE? What's the difference between 2.3.1 and 2.3.1SDK? And what's 2.3.1BSF Annotator? > > -Marshall > >> --Thilo >> >>> Thanks. -Marshall >>>>> eclipse update site: >>>>> >>>>> https://svn.apache.org/repos/asf/uima/uimaj-eclipse-feature-runtime-2.3.1-rc1 >>>>> >>>>> https://svn.apache.org/repos/asf/uima/uimaj-eclipse-feature-tools-2.3.1-rc1 >>>>> >>>>> https://svn.apache.org/repos/asf/uima/uimaj-eclipse-update-site-3-rc1 >>>>> >>>>> (In the next release, the uimaj-eclipse-feature runtime & tools will be >>>>> part of >>>>> the svn tag for the uimaj-distr.) >>>>> >>>>> Thank you for your votes :-) >>>>> >>>>> Vote open for 72 hours. >>>>> >>>>> [ ] +1 >>>>> [ ] 0 >>>>> [ ] -1 >>>>> >>>>> -Marshall >>>>> >>>>> >>
