Hi,

Thanks for the input Julian & François.
I'll take on the task to create and document this first release.
Will also first take a good look at how other projects handle this and use
and adapt this documentation to work for us.

Cheers,
Hans


On Mon, Nov 30, 2020 at 10:19 PM <[email protected]> wrote:

> Hi,
>
> It's very usefull to document and validate all the steps of the release
> process because you can spend a lot of time.
>
> You can also make some script helper to validate the release artifacts.
>
> There is some documentation on the Apache Confluence from other projects.
>
> Don't hesitate if you need help.
>
> regards,
>
> François
> [email protected]
>
> Le 30/11/2020 à 21:06, Julian Hyde a écrit :
> >> Mentors, do you have any input?
> > I was hanging back to see whether any other mentors had comments. (Also,
> > Thanksgiving.)
> >
> > I think you're in good shape to produce a release candidate - assign a
> > release manager, a release branch (or other means that you can identify a
> > particular git commit), create a tar ball, sign them, upload, send out an
> > email to start a vote on the tar ball. As you go, document the steps so
> > that the next RM can follow the same process.
> >
> > The first RC will fail, but will generate some issues that can be fixed
> for
> > the second RC. This may take a while. It might make sense to continue
> > feature development in the main branch.
> >
> > Julian
> >
> >
> >
> > On Mon, Nov 30, 2020 at 12:38 AM Matt Casters
> > <[email protected]> wrote:
> >
> >> Sounds good indeed.  We're still cleaning up code and fixing things left
> >> and right but it 'feels' like we could produce a nice useful release at
> >> this point.
> >>
> >> Cheers,
> >> Matt
> >>
> >> On Mon, Nov 30, 2020 at 8:33 AM Bart Maertens <[email protected]>
> >> wrote:
> >>
> >>> Hi Hans,
> >>>
> >>> Thanks! A code only release sounds good to me.
> >>> Mentors, do you have any input?
> >>>
> >>> Regards,
> >>> Bart
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Nov 25, 2020 at 9:43 AM Hans Van Akelyen <
> >>> [email protected]>
> >>> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> We have come at a point that we should discuss creating our first
> >> Apache
> >>>> release version.
> >>>> One of our mentors suggested that our first release be a source code
> >> only
> >>>> release to reduce complexity of the release and to see if our code
> >> passes
> >>>> the checks done by the IPMC. I suspect that our mentors will also
> first
> >>>> take a good look at this first candidate and point us to possible
> >> issues.
> >>>> We have checked all the dependencies we currently use and have the
> >>>> following ticket to do the follow up on work items [1]. Question to
> the
> >>>> mentors, does this have to be included in the release somewhere?
> >> release
> >>>> notes/disclaimer ?
> >>>>
> >>>> Another thing that has also already been done is checking all header
> >>> files,
> >>>> we have a couple of files that will need removal in the future when an
> >>>> alternative is created. These files have been listed in the LICENSE
> >> file
> >>>> [2]. Mentors, is this sufficient?
> >>>>
> >>>> So to summarize, does everyone feel comfortable with a source only
> >>> release
> >>>> as a first version?
> >>>> And do the mentors see any red flags or have a list somewhere on
> things
> >>>> that are checked, I went over [3] and it looks like we comply.
> >>>>
> >>>> Cheers,
> >>>> Hans
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/HOP-2182
> >>>> [2]
> >>>>
> >>>>
> >>
> https://github.com/apache/incubator-hop/blob/20aea10eaf497cf1be7251af4e352deb1cc6a53a/LICENSE#L206
> >>>> [3] https://incubator.apache.org/guides/releasemanagement.html
> >>>>
> >>
> >> --
> >> Neo4j Chief Solutions Architect
> >> *✉   *[email protected]
> >> ☎  +32486972937
> >>
>

Reply via email to