It seems aggressive to delete docs just because a line hasn't had a recent
release. We don't have a formal EOL policy for release lines, and old
releases (particularly old clients) are still used and old docs linked in
places.
Also, sorry if I missed the original rationale, but what do we gain fro
If propose keeping the last patch release on each X.Y branch and only keep the
versions that have been being maintained (a patch release in the last year?)
recently.
Thoughts?
.. Owen
> On Jun 28, 2018, at 19:19, Steve Loughran wrote:
>
> Rm'd all of 3.0.0-* ; left the current/stable symlink
Rm'd all of 3.0.0-* ; left the current/stable symlinks alone
On 27 Jun 2018, at 21:17, Sean Busbey
mailto:bus...@cloudera.com>> wrote:
3.1.0 was labeled "not ready for production" in its release notes[1].
Seems that means 3.0.3 is the stable3 release?
Speaking with my HBase hat on I'd rather "
IMHO dump the docs from the beta release as well. anyone on an
alpha/beta release should move on to a GA release and beta1 should
have been API frozen compared to GA.
3.1.0 was labeled "not ready for production" in its release notes[1].
Seems that means 3.0.3 is the stable3 release?
Speaking with
I'm looking at our svn site, and there are a lot of javadocs there, including
those for all the 3.0.0-alphas
du -s -h r3*
438M r3.0.0
1.2G r3.0.0-alpha1
368M r3.0.0-alpha2
368M r3.0.0-alpha3
374M r3.0.0-alpha4
425M r3.0.0-beta1
441M r3.0.1
441M r3.0.2
447M r3.0.3
467M r3.1.0
I propose: rm -rf
