Yes, this makes sense for Scandium. In Californium, we really need to look into alternative transports, first and foremost
the TCP binding. Most likely it will break the API. Thus, I want to develop 2.0 in the master. Now: Do we need every branch in every sub-project? It might suffice to only make sure every release has each sub-project in the same version. SNAPSHOTS could depend
on lower versions to minimize maintenance effort…
Parent:
-
only metadata, no real development
Element-connector:
-
currently I cannot see a 2.0 here
à 1.0.x
Scandium:
-
1.0.x for quick fixes, mainly for Leshan
-
1.x.x for your non-API-breaking development
à master since main
dev?
-
2.x.x unknown, maybe experiment with the reactor pattern
Californium:
-
1.0.x for quick fixes
-
1.x.x unknown
-
2.x.x for alternative transports, including HTTP cross-proxy based on Netty
à master as main dev
and to quickly push TCP?
Tools:
-
need a branch for each API version
à 2.x.x as master
What do you think? Will different versions in the master be confusing? Are all three levels (1.0.x, 1.x.x, 2.xx) in all
repos manageable?
Ciao
Matthias
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Hudalla Kai (INST/ESY)
Sent: Mittwoch, 13. Januar 2016 12:07
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: Re: [cf-dev] Branching strategy
The release build should not care about the version semantics, i.e. we could also release a version called “SUPERDUPER” and then set the next-release-version
to “2.0.0-SNAPSHOT”.
However, I think that we should also have a 1.1.0 (and maybe a 1.2.0) before finally reaching 2.0.0 because there will be improvements and/or new
features that will not break the API (and thus MUST only be available starting with 2.0) but provide a lot of value. In particular, I would like to re-factor the DTLSConnector to make it more modular and share UDP transport with the element-connector. I also
would like to try to improve its throughput by making message processing multi-threaded etc.
Then let’s prioritize the 1.0.1 release and do that in master. Once this is done, we can do the branching. I would like to have 2.0 as master, since
the TCP binding is the next big todo and is 2.0 dev...
Kai, can we simply release 1.0.1 although the master is already 1.1.0-SNAPSHOT?
I can then merge blockwise-no-rst and we can trigger a release.
Ciao
Matthias
if no much dev is planned for 2.0 now we can also say the master is 1.X and wait for more commitment to 2.X for creating the 2.X branch?
Anyway Leshan needs the last Cf fixes so we are willing to release a bugfix release ASAP.
Julien
On Sun, Jan 10, 2016 at 12:12 PM, Kovatsch Matthias <kovatsch@xxxxxxxxxxx> wrote:
Hi
I would use the master for the 2.0 development, basically just like Julien described it.
Apparently, we should merge the blockwise-no-rst branch for 1.0.1, the RD stuff, and the
Scandium fixes you worked on.
Ciao
Matthias
That's what we do for eclipse LDT, this works well.
Le 05/01/2016 16:23, Julien Vermillard a écrit :
I think it depends of what we want to do for 2.0.
if it's a full active fork I think we can have 2.0 dev in the master and create a 1.0 branch for 1.0 fixes.
1.0.x releases will be tagged from 1.0 branch.
2.0 milestone releases will be done from the master.
If of course the most active branch is 1.0 we can do it reverse way: a 2.0 branch for 2.0 dev and 1.0 fix in the master.
My 2 cents.
On Tue, Jan 5, 2016 at 3:32 PM, Hudalla Kai (INST/ESY) <Kai.Hudalla@xxxxxxxxxxxx>
wrote:
Hi committers,
over the holidays I spent some time trying to figure out a workable branching strategy for Californium that would allow us to go on with developing new features and re-factoring code while at the same time always be able to publish bug fix releases and have
a stable reference code base that can be used for deployment.
Now that we have shipped the 1.0.0 release of Californium I think it is time to more formally define the branching rules we want to follow in order to achieve these goals. We already feel the need to create a 1.0.1 bug-fix release that would allow Leshan to
(finally) use a relased version of Californium ...
I stumbled across this nice blog post [1] by Vincent Driessen which, from my point of view, looks like a good candidate for our purposes.
What do you think?
Regards,
Kai
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|
