7 Oct
2010
7 Oct
'10
10:51 a.m.
On 10/07/2010 03:24 AM, Marius Dumitru Florea wrote:
If the changes appear to be comparable then they should go from commit to release without
any
further testing, milestones or release candidates?
On 10/06/2010 03:28 PM, Caleb James DeLisle wrote:
Let's take for example the administration application which is included in each
release of enterprise.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4/pom… <--
v1.37
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.1/p… <--
v1.38
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.4.2/p… <--
v1.39
in v2.3
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3/pom… <--
v1.33
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.1/p… <--
v1.34
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.3.2/p… <--
v1.34 with a
comment above that 1.35 is incompatible.
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2/pom… <--
v1.26
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.1/p… <--
v1.27
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.2/p… <--
v1.28
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.3/p… <--
v1.29
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.4/p… <--
v1.30
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.5/p… <--
v1.32
http://svn.xwiki.org/svnroot/xwiki/enterprise/tags/xwiki-enterprise-2.2.6/p… <--
v1.33
So in the last three versions, every time except for 1, this was the practice.
I have been observing problems with the
versioning scheme which we are using.
Because applications are not branched along with
core, when a bugfix version of a stable branch is
released, new versions of applications are typically pulled in.
I'm not sure what you mean by "typically" here but I don't see the need
to automatically release an application whenever a bug fix release of XE
is made and I don't think our release managers do this. If an
application has bug fixes too and these bug fixes are compatible with
the bug fix release of XE then yes, otherwise the application needs a
branch.
Branching to keep bug fixes to backport separate from regular development is a good idea,
but in
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/branches/ I only see 4
branches have
ever been made.
This means that `experimental' code
is being introduced into a `stable' branch in a bugfix version.
That's not true. When you commit to an application you have to check
which versions of XE depend on it and if your changes are not compatible with all of them then you have to make a branch.
I'm not convinced that synchronizing version numbers is a good idea. I'm
-0 for now.
Thanks,
Marius
This is not the path I would choose
but more importantly we can't honestly say that our code goes through a
milestone/release candidate
verification process if some of the code is allowed to bypass it.
This situation has caused me to make a mistake which I was able to correct during the
release
without major issue, I think the same issue is behind the release of 2 bogus versions
(2.4.1 and 2.4.2)
There is another issue, users who want to mix and match applications to build their own
wiki are
faced with a set of version numbers and no way to know what is compatible with what. A
user who I
spoke with last night had this very problem. We could publish a compatibility matrix but
if we were
to show all the versions a given application is compatible with, that would require
testing each
application version against each core version and I think we need to concentrate on
testing what
gets released in XE.
Both of these problems would be fixed if version numbers were synchronized and everything
was
branched for a release. Relevant questions which come to mind are "do we need the
capability to
release applications at separate times?" and "is there no way to do that with
synchronized version
numbers?"
Am I missing any other reasons?
Should this not become a proposal?
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs