| Re: [jakartabatch-dev] GitHub milestones for EE 10 , Batch 2.1 (tentative) |
"jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx> wrote on 04/05/2021 01:38:48 PM:
> From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
> To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
> Date: 04/05/2021 01:39 PM
> Subject: [EXTERNAL] Re: [jakartabatch-dev] GitHub milestones for EE
> 10 , Batch 2.1 (tentative)
> Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
>
> Le lun. 5 avr. 2021 à 18:08, Michael Minella <mminella@xxxxxxxxxx> a écrit :
> Is this intended to be a 2.1 (backwards compatible) or a 3.0
> (breaking changes allowed) release? A quick scan through the issues
> makes me think this should be more of a 3.0 than a 2.1. Specifically:
> CDI requirement is a breaking change.
>
> Is it? Was already the case AFAIK - or more exactly I expect it to
> be the same as current version since CDI support is in and all other
> CDI features are about CDI integration more than requirement.
I don't see this adding CDI support as a breaking change. I'm pretty sure not if we go the route of defining Batch + CDI integration only "when CDI is present", and it might note even be breaking if we say Batch + CDI integration is simply required.
For it to be "breaking", wouldn't you have to imagine an app that would have used CDI in some manner if Batch did integrate with CDI, but didn't because Batch + CDI integration was not defined, but now would use Batch + CDI integration and break ? Is this really a concern?
> Adding generics and a Java API, while not a breaking change, is a
> change big enough IMHO to warrant a major version bump.
>
> If possible I'd stay on a minor since it will enable everyone to
> upgrade smoothly anyway (vs major bumps can require to wait some
> time for projects). That said not sure much people moved to 2.0 and
> if very few I guess we can go this way which makes sense if
> possible, if we have figures it can help to decide maybe central ones?.
I'm of mixed opinion on this one, and viewing this decision as TBD... and am therfore thinking of this the "tentative 2.1 plan"
For the generics, as noted before, we could go either way: either add them in a non-breaking manner, e.g. a separate set of TypedXXXX classes, (TypedItemReader<T>, etc.) or make a breaking change from ItemReader -> ItemReader<T> the next time we do a major release.
I think if I were looking at this feature list right after we finished 1.0, I'd say of course this is a big enough change to warrant a major release.
I'm not sure what feature we're ever going to add that will be as a significant change as Java-defined jobs.
On the other hand, starting from zero velocity, with me personally only able to commit to this on a part-time basis, (and I'm imagining most participants will be in similar situations), it seems too ambitious maybe to say we're doing a major release.
Though we didn't let that stop us from doing the 1.0->2.0 jump, but that was a special case. And if we truly need to do a breaking change then bumping the major release is the right thing.
But I'd like to see how this goes.
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------