Re: [el-dev] Release process

[Mark Thomas <markt@xxxxxxxxxx>]

On 07/03/2020 21:04, arjan tijms wrote:
> Hi,
> 
> My preference would be for 3 (split into two Eclipse projects) for the
> medium to long term. 

That works for me.

> Every upstream project can of course decide what it wants to use for a
> compatible implementation, and this may or may not be the new Eclipse
> project created from the implementation of EL-RI. If the new Eclipse
> project withers after some time then it is what it is. Like all OSS
> projects it stands or falls with people interested in it. 
> 
> I myself would at least be interested in splitting it off, doing the
> work to get it setup and released as a separate project and implementing
> new spec features in it.
> 
> If we intended to release more RCx versions for Jakarta EE 9 I'd be okay
> it people want to give option 4 a try.

I was thinking about an RC-2 but I don't think we'll need it.

Unless there are any objections I believe the API repo is in a fit state
to do the final release.

I'd prefer to do an API only release but that could be a combined
release if the impl is in a suitable state. Is it?

As per the discussion on the spec leads list, I'm going to start the
process for the 4.0.0 final release.

Mark


> 
> Just my thoughts.
> 
> Kind regards,
> Arjan
> 
> 
> 
> On Sat, Mar 7, 2020 at 9:45 PM Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>> wrote:
> 
>     So, the question has arisen how do we do releases?
> 
>     We have the API and the impl in the same repository. They share version
>     numbers.
> 
>     We can release the API, the impl or both.
> 
>     If we release the API and the impl at different times it causes various
>     complications - mainly around version numbers and tags generated by the
>     CI based release process.
> 
>     How do we want to address this?
> 
>     Possible options (just a quick brain dump - there are probably more)
> 
>     1. Always release API and impl together.
> 
>     2. Separate the API and impl into separate repositories.
> 
>     3. Separate the API and impl into separate Eclipse projects.
> 
>     4. Update the CI process to somehow manage the process better (some sort
>        of naming convention for the tags?).
> 
>     And a rather more radical:
> 
>     5. Drop the implementation and use a different implementation as the
>     compatible implementation.
> 
> 
>     I'm not sure option 1 would always be possible - or releases would be
>     delayed while the other component was brought up to a releasable state.
> 
>     Option 4 is probably the simplest to implement.
> 
>     Options 2, 3 & 5 will all require some degree of administrative work.
>     I'm assuming 2 would require the least and 5 the most.
> 
> 
>     My own preference is for 5 as my involvement in EL has historically been
>     only with the spec and the API and those are why I am here. I don't have
>     the time (or the interest) to get involved in the implementation. That
>     said, I don't want to get in the way of others who do want to work on
>     the implementation. If we can find a way to work that allows the API and
>     impl to continue in the same repo and/or project without treading on
>     each others toes I'd be fine with that.
> 
>     Mark
> 
>     P.S. For "API" in the above, read "API/spec"
>     _______________________________________________
>     el-dev mailing list
>     el-dev@xxxxxxxxxxx <mailto:el-dev@xxxxxxxxxxx>
>     To unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/el-dev
> 
> 
> _______________________________________________
> el-dev mailing list
> el-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/el-dev
>