accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <>
Subject Re: [DISCUSS] Official release dates / DOAP out-of-date
Date Wed, 07 Sep 2016 14:03:26 GMT
I prefer SVN dist date, but I know that isn't the easiest to come by ... I
recall approximating the date on a couple of occasions when i couldn't
figure it out readily. Another possibility is to use the archive,, assuming that a release hits the
archive on approximately the same date that it is released to dist. Archive
is down sometimes, though.

Anyway, announce date would be fine too if we can't find a way to use the
actual distribution date.

On Tue, Sep 6, 2016 at 4:36 PM, Christopher <> wrote:

> I noticed that there were a few missing releases in our DOAP file, and I
> also noticed lots of discrepancies between what's in JIRA as the release
> date, when the tag was created, when the announcement was made (and on
> which list), what the date was in, and what the date
> was in DOAP.
> There are 3 places we record the "official" release date:
>  * doap_Accumulo.rdf
>  * JIRA
>  *
> Reporter actually has a sync-to-JIRA feature (but it's off-by-one... I'm
> investigating that), and I'd like to just use that feature rather than try
> to manually keep things sync'd up there also, so that leaves just 2 places
> to update.
> There are several sources we can use for the "official" release date:
>  * SCM tag date
>  * Date uploaded to SVN dist
>  * Announce email date
>  * Vote date
> I don't like using the vote date, because that doesn't say when the release
> occurred, just when we agreed on what will comprise the release. SVN dist
> might technically be the best date to use, but it's a pain to track that
> down, and it typically precedes the announcement by at least 24 hours. I
> think I like announce date the best, but we actually forgot to announce on
> at least one occasion, and we sometimes announce on different lists (dev@
> user@ announce@).
> Even if they are wrong, I'd like to sync up these different locations, so
> they don't show different dates for a release... and I'd like to decide on
> a standard from now on, so we know what a date means, and it doesn't vary
> so much.

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