tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Meikle" <loo...@gmail.com>
Subject Re: TIKA 0.2 Release
Date Sun, 16 Nov 2008 22:22:50 GMT
Moving the discussion on the list.

See additional comments below.


2008/11/16 Jukka Zitting <jukka.zitting@gmail.com>

> Hi,
> As a meta comment, it would be better if we had this discussion on
> tika-dev@. If you agree, feel free to forward my response there.
> On Sun, Nov 16, 2008 at 6:23 PM, Dave Meikle <loompa@gmail.com> wrote:
> > * Release Artifacts *
> > Given the situation with PDFBox I was thinking about just not releasing
> the
> > standalone version of Tika, but as there are options should I hold a
> quick
> > vote on the list for the best way to do this?
> Sounds good to me. I think it's good enough if you just send a summary
> of what you plan to do, i.e. a "Tika 0.2 release plan". A vote is only
> needed if people disagree and a reasonable consensus can not be
> reached through discussion.
> > Also, I was planning to use the release version 0.2 instead of
> > 0.2-incubating - I assume this is OK as the vote for graduation has
> passed
> > or is there another formal step that has to take place first?
> Yes, good point. I updated the version label in Jira accordingly.
> > * Web Site *
> > For the website I have been spending some time updating the pages,
> focusing
> > on the formats and then the documentation. As I will need to update the
> > whole site for the download I was wondering if I should be updating all
> the
> > references to incubator to lucene for the move? (Much the same as the
> > version number above)
> >
> > Based on the above answer that will decide my links for the downloads.
> I just committed some related changes, I hope I didn't conflict with
> your changes. In any case; yes, we should update the site to reflect
> that Tika is now a part of Lucene instead of the Incubator.
> > * Release Process *
> >
> > I was planning to take a branch for all the tweaks that are release
> > specific, tag that, build release candidate from the tag, raise vote,
> etc.
> > At the end the tag could be copied and the changes merged into head. This
> > was to avoid updating HEAD resulting in having the version number updated
> > for anyone how takes a checkout and the site updated, as I believe this
> is
> > being done as the result of a cron script in your pao account.
> >
> > Is this an OK way to do it? Was going to document the process I followed
> > somewhere so we can refine as an ongoing guide.
> Yeah, you'll want to drop the -SNAPSHOT from the version number only
> in the 0.2 branch.
> However, I don't see what 0.2 -specific changes there are that would
> then need to be merged back to the trunk. The web site is a live
> publication that should always be updated in the trunk.

What I was thinking about was the changes to the website to reflect the 0.2
download URLs. We won't want them "live", when the release candidate is
being voted on, and potentially a cycle of candidates taking place.

> BR,
> Jukka Zitting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message