I’d agree- it’s a “feature” of GitHub and I didn’t see a way to turn off
“turning a git tag into a release”

I see that there is a API to edit a release to say it is “pre-release”
https://developer.github.com/v3/repos/releases/#edit-a-release

IMO either way it should be ok because
a) the tag is clearly indicating *-rc0 *-rc1 and so on (if not ok, it can
be set as a prerelease)
b) when a new RC is being rolled, the last RC git tag can be removed (which
should also eliminate the github “release”)
c) when the RC becomes the official release, the git tag can be replaced
and the final git tag is the release


On Fri, Feb 8, 2019 at 11:14 PM Seunghyun Lee <sn...@apache.org> wrote:

> Hi all,
>
> I'm Seunghyun who's working on the first Apache release for Pinot project.
>
> When I played around with maven-release-plugin today, I found out that
> Github would automatically generate the release at "
> github.com/apache/incubator-xxx/release" when we update the tag. I think
> that some projects may inadvertently create a release on Github for their
> release candidates.
>
> I'm a bit confused because we need to provide the tag as part of release
> process while tagging a release candidate creates a release on Github.
>
> If you refer to the Gobblin's release page [1], you can observe that
> release candidate was added to the release page before the official release
> got updated. I have looked into Github configurations, I haven't find one
> that prevents this yet.
>
> Best,
> Seunghyun
>
> [1] https://github.com/apache/incubator-gobblin/releases
>
>
> On Fri, Feb 8, 2019 at 7:57 PM Dave Fisher <dave2w...@comcast.net> wrote:
>
> > Hi Julian,
> >
> > A perfect example!
> >
> > I think we should add a checkbox to the podling report where the podling
> > indicates when they are fully in compliance with release policy. Until
> that
> > is done we don’t worry.
> >
> > Additionally, Infra could tag and “release” with appropriate description
> > when they move a GitHub repository into the foundation.
> >
> > Regards,
> > Dave
> >
> > Sent from my iPhone
> >
> > > On Feb 8, 2019, at 5:41 PM, Julian Hyde <jh...@apache.org> wrote:
> > >
> > > I’m a mentor of Druid.
> > >
> > > We allowed Druid to continue making releases outside of Apache during
> > incubation because ASF releases were not possible. There were various
> > reasons - they could not release from main line because IP transfer had
> not
> > been completed (if I recall correctly), and they also needed to make
> > bug-fix releases of existing releases. Druid is an active project with
> > large installations in production, some of them at major companies;
> pausing
> > releases for 6 - 9 months while transitioning into ASF would have been
> > hugely damaging to the project and its community.
> > >
> > > The project tried to do everything by the book: they sought permission
> > for releases outside of ASF, disclosed the non-ASF releases in its
> reports,
> > and made an official Apache release as soon as they could. If there is
> > anything they could/should have done differently, let’s discuss, and
> write
> > down guidelines for future podlings that are in a similar situation.
> > >
> > > Julian
> > >
> > >
> > >
> > >> On Feb 8, 2019, at 5:16 PM, Justin Mclean <jus...@classsoftware.com>
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >> One of the issues I’ve seen is that project continues to make releases
> > in GitHub after being accepted into the incubator, in some case is this
> > because the repo hasn’t been moved over yet, in other cases it’s because
> > they believe that the code base is not Apache ready. What should we do in
> > this situations? From what I seen it usually just delays transfer of the
> > repo and encourages unapproved releases. I would would push for mentors
> > speeding up that transfer rather than allowing unapproved releases. What
> do
> > others think?
> > >>
> > >> Thanks,
> > >> Justin
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Reply via email to