Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jms-dev] Proposals repository

Certainly a worthy approach. Are you going to port over the older issues that Nigel Deakin had groomed? If not, you and I should talk and I can help do that if you can point me in the right direction.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On 2/27/2020 9:02 PM, David Blevins wrote:
I've opened a ticket to get us a new repository called `jms-proposals`

The intent is it will be modeled after this pattern:


Here's the concept in practice:

 - Every idea/proposal gets a directory and readme and things can be merged pretty much immediately
 - The README would describe the idea and motivation
 - The src/main/java would contain the proposed API classes
 - The src/test/java might contain any associated TCK tests or mock usage
 - If someone likes an idea but imagines it slightly differently they can copy the dir and tweak it

Things would graduate from the proposals repo to the main jms-api repo only one there's someone who actually implements it.

The primary motivation is to give everyone as much flexibility as possible to propose ideas in any state of polish, while keeping us honest.  A good idea is just an idea till some one implements it.  We don't want to put people in the position to watch their proposal get removed from master because we need to do a release and it isn't supported by anyone.  We also don't want to make someone feel alternate proposals are not welcome because one is already sitting in master occupying "the" slot or something else proposed conflicts.

You would be able to propose an idea in any state of polish.  To have it graduate, you'd need to do all the work or convince someone else to do all the work (api, spec, tck, impl).

The delta between those two is several months, so PR is also not quite great either.

We could potentially do releases from the proposals repo into a clearly non permanent groupId such as `org.eclipse.jakarta.messaging.proposals`

The main API repo would stay in an always releasable state while ideas can have as long as they need to incubate.

At least that's the idea :)

David Blevins

jms-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Reza Rahman
Principal Program Manager
Java on Azure

Please note that views here are my own as an individual community member and do not represent the views of my employer.

Back to the top