Hi,
from the release timing, I think we have the spec version bump at the
wrong time right now.
Here is what we do:
Once we start the release process, we create a new branch "delivery",
which will become the final release. Once "delivery" is created
"master" is open for feature work. Over time bugfixes are applied to
"delivery" and features and bugfixes go into "master". When the new
version is released, it gets tagged and "delivery" is merged into
"master" to get all bugfixes from "delivery" into "master". After that
is done, a final "spec version bump" commit is done and pushed to
"master".
While release is in the works, both "master" and "delivery" have the
same spec version and this is problematic. Consider the case, where a
new feature is merged to "master", now you want to depend on this
feature. To do this, you set your dependency version to the spec
version of the module. But on what version of the module do you depend?
On the one in master or delivery? You need the master one, but can't
specify that.
So I suggest, that spec version increment happens as the second commit
directly after delivery is branched of. That way this we get:
master
spec: 1.0
|
^
/ \
/ \
/ \
/ \
| |
| |
spec inc. |
| |
| |
master delivery
spec: 1.1 spec: 1.0
| |
| |
| release
| |
| |
+<--------+
|
master
spec: 1.1
|
As master will get all commits from delivery, the requirement, that 1.1
is a superset of 1.0 is fullfilled. If you need a new feature, you will
depend on spec version 1.1, else you use 1.0. Of course you can deliver
your new plugin only after the next version (that with spec version
1.1) is released, but you know, that so you are happy.
Does that make sense to you?
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
