[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-dev] [External] : EclipseLink 3.0 branch
|
Hi,
> On Feb 9, 2021, at 12:10 AM, William Dazey <dazeydev.3@xxxxxxxxx> wrote:
>
> Hello
>
>
> @Lukas Jungmann
>
>> Even master is already producing snapshot builds, ie for end-user bug fixes testing, see https://urldefense.com/v3/__https://jakarta.oss.sonatype.org/content/repositories/snapshots/org/eclipse/persistence/eclipselink/__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9Onp37Glg$
>
> That's gonna need to stop and be switched over to a new 3.0 branch
> then, right?
No, new jobs will have to be set up for the new branch - we want to allow users, or even ourselves, to easily use/test the latest greatest SNAPSHOT bits from each maintained branch, don’t we?
And for every bug fix this is what will have to be done (in the “ideal” world):
- create a PR against master and wait for the review
- test locally and/or wait for tests to finish
- wait for merge
Repeat for each maintained branch (where branch is: “new one”, 2.7, 2.7_WAS(?), 2.6, 2.6_WAS(?)):
- once it’s merged to the (branch + 1), create new PR against the (branch) cherry-picking(*) the change from (branch + 1)
- test locally and/or wait for tests to finish
- wait for merge
and additional jakarta->javax change needs to be done when backporting from 3.x to 2.x versions
(*) cherry-pick can, at least in some cases, handle relocations done between 2.7 and 3.0 with appropriate local repo setup (merge.renamelimit=999999 helps on my end)
So we’ve already added more work to back porting, why should we add additional round of testing etc for something what needs to get out from the doors in less than 3 weeks?
… I’m aware that we are not following that properly in all cases as quite often there are PRs against all maintained branches being done at once (and yes, even by myself); and there is also an option the back port more changes at once to eliminate few rounds of testing
> I don't feel like we should be cutting releases of
> master. It may be "fine for now" and it hasn't caused any issues yet,
> but I think 3.0.x needs its own service stream similar to 2.6 and 2.7.
> In my mind, "master" is where current development is contributed. New
> features that may be in the next specification or large enhancements
> that break backwards compatibility are submitted in "master". When we
> released 3.0.0 and cut the version, I thought we had forked a "3.0"
> service branch at the same time. I didnt notice and I missed it until
> now.
I agree we need a service branch for 3.0.x versions like we have for 2.7.
I see nothing bad in releasing from master, it’s IMHO a matter of taste (but not only, ie project specific dev life cycle can come to play).
As long as there are no breaking or potentially dangerous changes for master available, I see no point in adding additional overhead by requiring all committers to maintain additional branch
> The whole reason I am bringing it up is because I was working on an
> enhancement to EclipseLink that breaks backwards compatibility for
> EclipseLink API. It might be ok for the next major release... but I
> wasnt thinking about including it in 3.0.0 and possibly breaking users
> that rely on the API how it exists!
Great you have something! The question is:
Can you wait till 3.0.1 gets out from master (and 3.0 branch gets created) - RC should be by the end of Feb (so in < 3 weeks)
Or
Do you need it in master now/sooner?
(It’s about 1person creating draft PR with `git rebase master` before merging it when the time comes vs requiring all committers doing bug fixes back porting them to one additional branch)
>
>> Does master already contain something we don’t want to have in 3.0.1 (in the other words - branch from HEAD or Tag and backport what we want)?
>
> I honestly don't know since I can't speak to all the changes. GitHub
> lists 6 commits that have been delivered to master since the release
> of 3.0.0: https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/compare/3.0.0...master__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9Onb5girY$
>
> One of them, Bug 570378
> (https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/pull/1000__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OnUtFbZ8$ ), is a fix I
> introduced and is good for 3.0.x. I am also more than happy to create
> a new PR to port this change to a "3.0" service branch if we fork from
> the tag for "3.0.0", which is how I think we should do it.
Our 5 commits are also target to 3.0.1, so current master’s HEAD is what we want to have in 3.0.1.
>
>> If we create a branch for 3.x, then it would be probably better to jump to version 4 in master and require SE 11 as minimal supported java version there. What do you think?
>
> I am not against having master jump to version "4.0.0" after we fork
> "3.0" as its own branch. I don't know what our plans are for the
> future.
Neither do I yet.
From what I got to know on today’s Jakarta EE platform dev call:
- next version after 9.1 (should get out in March/April) will be either 9.2 or 10 - depends on the versions of specs included there. If at least one changes major version number, then the version will be 10, otherwise 9.2
- intention is to define Java SE 11 as minimum required Java version
- expected release date is tentatively by the end of this calendar year
- each spec has to submit a plan of changes for review by April 15; the plan should focus on things which can be implemented by and delivered in compatible implementations in 6 months
(- there was also some discussion about allowing specs and implementations supporting new JDK features etc, for us that would mean ie Java records, but I don’t see that mentioned in meeting minutes)
> We currently have the EclipseLink version (3.0) match the JPA
> Spec version (3.0)! I think that is more of a coincidence, but it
> would be interesting if we planned on keeping pace in some way.
> *shrug*
Version number of the spec depends on what changes will be done there at the spec level.
> I see no reason to confuse users any further with different
> version values and what JPA lvl that lines up with ect.
> I would like to suggest a versioning strategy in which a major version
> increment (for instance, 3.0.x -> 4.0.x) conveys that there is no
> guarantee of backwards compatibility.
I’m thinking towards having “some version” with Java SE 11 as the base level where we could play with JPMS, new JDK features, simply said something not too constrained by backwards compatibility rules to work on and also have some fun and ability to learn new things from the world outside of EclipseLink. This can also work as a base for possible back ports of SE 11 related changes back to 3.x versions (even if at some point we realize that we need sth like 3.1 to match the spec, we will be able to do it).
>
> major.minor.micro-qualifier
> ```
> major: a breaking change
> minor: a backwards compatible change
> micro: a bug fix (no API change)
> qualifier: a new build
> ```
> ie. "3.0.0-RC2"
>
> I think this is a good strategy for versioning going forward.
Well, for last couple years, change in minor number signalled change in minimum supported Java SE version and (almost) nothing else
Thanks,
—lukas
>
> Thanks,
> Will Dazey
>
>
> On Mon, Feb 8, 2021 at 3:14 PM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
>>
>> On Feb 8, 2021, at 8:52 PM, William Dazey <dazeydev.3@xxxxxxxxx> wrote:
>>>
>>> Hello!
>>>
>>>> What the version number in master is going to be then? Or probably better question - do we need to have master at say 3.1.x and branch for 3.0.x now?
>>>
>>> I agree that "3.1.0" sounds like a good place-holder version for master going forward. If something happens and we want "4.0", or something like that, then we can change the version before we build. I am not really too concerned with masters version because that should be the HEAD of development and not build/released anywhere. I am more just advocating for an official "3.0" release service branch for us to commit non-breaking bug fixes into the 3.0 release.
>>
>> Even master is already producing snapshot builds, ie for end-user bug fixes testing, see https://urldefense.com/v3/__https://jakarta.oss.sonatype.org/content/repositories/snapshots/org/eclipse/persistence/eclipselink/__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9Onp37Glg$
>>
>>
>>>
>>>
>>>> There is 3.0.0 tag - https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/releases/tag/3.0.0__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OuP-mYPo$ - corresponding to 3.0.0 final build. Should we need to create a branch for 3.0.x, then why not from that tag?
>>>
>>> I do think we should create a branch for "3.0.x" for service/bug fixes and future releases of 3.0 would be incremented and built from that branch; just the same as 2.6 and 2.7 before. It appears that "releases/tag/3.0.0" is on commit "commit/3986bdbeae8e0e04e5be4a7076f2bda2ee1a09a5", which matches the maven central bundle version information I found. I see no reason we cannot create a branch from that tag since they both appear to point to the same commit.
>>
>>
>> Does master already contain something we don’t want to have in 3.0.1 (in the other words - branch from HEAD or Tag and backport what we want)? If we create a branch for 3.x, then it would be probably better to jump to version 4 in master and require SE 11 as minimal supported java version there. What do you think?
>>
>> Thanks,
>> —lukas
>>
>>>
>>> Thanks,
>>> Will Dazey
>>>
>>> On Mon, Feb 8, 2021 at 1:37 PM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
>>> Hi,
>>>
>>>> On Feb 8, 2021, at 8:18 PM, William Dazey <dazeydev.3@xxxxxxxxx> wrote:
>>>>
>>>> Hello all!
>>>> I just noticed that I don't see a branch dedicated to release "3.0", similar to "2.7'' and "2.6". There is the branch "3.0.0-M2-RELEASE", but I'm not sure if that is meant to be the "3.0" release branch going forward. If so, I recommend we rename that branch to follow the naming convention of the previous release branches (2.6, 2.7, ect). Otherwise, I recommend that we create a new branch for 3.0, forked from master at the same commit that the initial release of EclipseLink 3.0 was released at.
>>>
>>>
>>> What the version number in master is going to be then? Or probably better question - do we need to have master at say 3.1.x and branch for 3.0.x now?
>>>
>>> Note that we should have 3.0.1 final around mid March (I think) for EE 9.1 and the scope of changes we can do there is rather limited (basically only improving support for SE 11 + bug fixes), so I would prefer to lower the overhead by not creating additional branch till Jakarta EE 9.1 gets out.
>>>
>>>> https://urldefense.com/v3/__https://mvnrepository.com/artifact/org.eclipse.persistence/eclipselink/3.0.0__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OpiYZe_0$ :
>>>> org.eclipse.persistence.version.properties:
>>>> ```
>>>> version=3.0.0
>>>> qualifier=v202012081010
>>>> buildDate=20201208
>>>> buildTime=1011
>>>> buildRevision=3986bdbeae8e0e04e5be4a7076f2bda2ee1a09a5
>>>> buildType=SNAPSHOT
>>>> ```
>>>>
>>>> which I believe matches commit: https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/commit/3986bdbeae8e0e04e5be4a7076f2bda2ee1a09a5__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OSJlvnLw$
>>>>
>>>
>>> There is 3.0.0 tag - https://urldefense.com/v3/__https://github.com/eclipse-ee4j/eclipselink/releases/tag/3.0.0__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OuP-mYPo$ - corresponding to 3.0.0 final build. Should we need to create a branch for 3.0.x, then why not from that tag?
>>>
>>> Thanks,
>>> —lukas
>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> Will Dazey
>>>> _______________________________________________
>>>> eclipselink-dev mailing list
>>>> eclipselink-dev@xxxxxxxxxxx
>>>> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!GqivPVa7Brio!PxKQl_ycAvAtnayPFwvN26D6s3Xx3-xqMaXIhDcyezybWAgMeFXJyzqYReIxVbrFHL4$
>>>
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@xxxxxxxxxxx
>>> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OqjbHVT8$
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@xxxxxxxxxxx
>>> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!GqivPVa7Brio!JU4XxNBliPkJHIOh7VRuxe7bedUmj3YNe4ldq0SWz8IccflL0ENl8-WI9TsCI8O8spQ$
>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OqjbHVT8$
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/eclipselink-dev__;!!GqivPVa7Brio!PGAtiRa4f2N0r9hr9f1ulVVnP3nzxq-brRae_CeQ-BJHbn1nScoKv4sbWU9OqjbHVT8$
