[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-dev] [External] : EclipseLink 3.0 branch
|
Hello
@Piotr Żygieło
> The PR 985 reveals the commit that 3.0.0-RELEASE branch was pointing at (dd5cf6aad9). Perhaps this could be considered, as it has versions for development updated already
I don't see a branch for "3.0.0-RELEASE"
(https://github.com/eclipse-ee4j/eclipselink/tree/3.0.0-RELEASE).
Based on PR 985 (https://github.com/eclipse-ee4j/eclipselink/pull/985,
was "3.0.0-RELEASE" from Radek Felcman's fork?
Also, I don't think "dd5cf6aad9e06cd2ad4a140d380abb976be5964b" is the
correct commit hash. Commit "3986bdbeae8e0e04e5be4a7076f2bda2ee1a09a5"
matches the version.properties file in
https://mvnrepository.com/artifact/org.eclipse.persistence/eclipselink/3.0.0
It is interesting that the tag "3.0.0"
(https://github.com/eclipse-ee4j/eclipselink/releases/tag/3.0.0)
appears to have its own commit
"3986bdbeae8e0e04e5be4a7076f2bda2ee1a09a5". However, if you view the
commit history for "master", you don't see this commit listed. I had
always thought tags were associated with OTHER commits and were not
their own commit... but that may not be important. What is important,
in my opinion, is that the "version.properties" file for the
EclipseLink 3.0.0 release lists tag 3.0.0's commit "3986bdb". That is
what we should fork from, in my opinion.
@Lukas Jungmann
> Even master is already producing snapshot builds, ie for end-user bug fixes testing, see https://jakarta.oss.sonatype.org/content/repositories/snapshots/org/eclipse/persistence/eclipselink/
That's gonna need to stop and be switched over to a new 3.0 branch
then, right? 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.
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!
> 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://github.com/eclipse-ee4j/eclipselink/compare/3.0.0...master
One of them, Bug 570378
(https://github.com/eclipse-ee4j/eclipselink/pull/1000), 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.
> 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. 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* 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.
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.
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://jakarta.oss.sonatype.org/content/repositories/snapshots/org/eclipse/persistence/eclipselink/
>
>
> >
> >
> > > There is 3.0.0 tag - https://github.com/eclipse-ee4j/eclipselink/releases/tag/3.0.0 - 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://mvnrepository.com/artifact/org.eclipse.persistence/eclipselink/3.0.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://github.com/eclipse-ee4j/eclipselink/commit/3986bdbeae8e0e04e5be4a7076f2bda2ee1a09a5
> > >
> >
> > There is 3.0.0 tag - https://github.com/eclipse-ee4j/eclipselink/releases/tag/3.0.0 - 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://www.eclipse.org/mailman/listinfo/eclipselink-dev
> > _______________________________________________
> > 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://www.eclipse.org/mailman/listinfo/eclipselink-dev
