Re: [el-dev] Release process

[arjan tijms <arjan.tijms@xxxxxxxxx>]

Hi,

My preference would be for 3 (split into two Eclipse projects) for the medium to long term. 

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. 

Just my thoughts.

Kind regards,

Arjan

On Sat, Mar 7, 2020 at 9:45 PM Mark Thomas <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
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/el-dev