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.
> 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.
-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
>>>>
>>>>
>
