Currently, our release process is fairly simple and reasonable, I think:
1. We typically are working on the next minor release (e.g.,
2.1.0-SNAPSHOT).
2. While working on the next minor release, we do micro releases for
the previous minor release (e.g., 2.0.1) if warranted.
3. Once the current trunk is done, we release (e.g., 2.1.0-SNAPSHOT
becomes 2.2.0 and trunk becomes 2.3.0.SNAPSHOT).
4. Go to step 1 and repeat.
So, the number of service releases depends on the number of issues that
arise between minor releases. Usually, it is one micro release for every
minor release...sometimes more, sometimes less.
Comparing this to Eclipse' release process, I think it is still
reasonable. From what I understand, Eclipse does one release a year and
commits to two service releases per release (over 8 months). And
components like Equinox might not actually change during service
releases if no issues arise. Since we release more quickly, I don't
think we could promise two service releases over a year after for each
minor release, it wouldn't be practical.
Perhaps one area where we could try to address your concern is around
what happens to minor releases after the next minor release? For
example, now that we have 2.0.0 out, we are working toward 2.2.0 via
2.1.0.SNAPSHOT, during which time we will release service releases for
the 2.0.0 branch. But what about our last minor release 1.8.x?
Yes, it is true that twice removed minor releases no longer receive any
love from us, but I think if people wanted to volunteer to backport
fixes to twice removed minor releases and do releases of them, I don't
see an issue with that as long as the fixes are minor and aligned with
future fixes.
So, for example, once 2.2.0 is out, if you want to continue to maintain
2.0.1 (or whatever micro version it is at that time), then I think we
could do that.
-> richard
On 10/7/09 2:33, Don Brown wrote:
I'm confused as to why not having a stable branch would even be an
option. Richard, if you found a deadlock problem in Felix in a
released version of Glassfish, surely you can't simply upgrade to the
latest Felix, and if you have a privately maintained stable fork, why
not have one that all Felix users can share? What do the rest of the
Felix users out there do about stable releases?
If it is a problem of resources, I'm confident that if you asked,
you'd get several volunteers like myself, because most likely, they
need to be maintaining a stable fork anyway, so why not share it with
the community. Trying to host a stable branch at another site isn't
really an option, because users want an "official" Felix release from
a group they trust, Apache, not some dodgy github fork or vendor
branch with selfish motivations. Furthermore, Felix users, like
myself, want a stable branch that is supported by the Felix project,
if for no other reason than only its committers seem to have access to
the test suite to test against possible regressions. There is
currently no way for me to know that if I backport a fix that I didn't
break something else. Sure, Atlassian products have a bunch of tests,
but we can't test every operation, every platform, every set of
possible bundles, and even, integration tests like those only go so
far.
It is especially important for a framework to have a stable branch
that your users can trust. Upgrading major versions of Felix is a
risky proposition that always results in at least a week or so of
issues, and that doesn't include the ones that pour in from support.
However, I have no choice since really critical fixes like deadlocks
and infinite loops are only fixed on trunk. Felix, being a core
framework, is at the bottom of the development stack and as such,
needs to be as stable as possible.
Again, I'm happy to do whatever work necessary to get stable releases
of Felix out, but as I said, I think having stable releases is a
fundamental requirement if Felix is meant to be used in supported
production systems.
Don
On Wed, Oct 7, 2009 at 8:29 AM, Karl Pauls<[email protected]> wrote:
On Tue, Oct 6, 2009 at 2:51 PM, Don Brown<[email protected]> wrote:
Great, but what about the 2.0 stable branch?
We don't really maintain a stable branch. We do so more or less on
purpose as trying to maintain branches would be a lot of effort and we
rather focus what resources we have to keep the trunk in a good shape.
However, some times we do backport some issue to a previous branch and
make a one off release if somebody really needs it but thats about it.
If need be, I'm happy to
volunteer to maintain it if no one else will, as I'll be maintaining a
branch/fork for Atlassian anyway.
Having your own branch/fork is certainly fine and thanks for
volunteering. However, we decided against maintaing branches at felix
and I'd rather like to keep it that way. If you or other want to do
that (either for their own or customers sake) thats ok and we will try
to help you wherever we can but I don't see the need to do this at
felix.
Thanks again!
regards,
Karl
Don
On Tue, Oct 6, 2009 at 6:01 PM, Karl Pauls<[email protected]> wrote:
On Tue, Oct 6, 2009 at 8:17 AM, Don Brown<[email protected]> wrote:
With 2.0.1 about to be released from trunk and several issues with
1.8.1, I made the leap to move Atlassian Plugins to trunk. Since I
need a release, I still forked, but hopefully won't need it after
2.0.1 for at least a little while. So far, most builds are green
(weblogic yet to run), so that's an improvement.
Anything I should be wary of? Will trunk turn into 2.0-stable or
should I plan on keeping my fork.
Yes, trunk will become 2.0.1. If nothing else is showing up I will cut
the release and call the vote on the weekend.
regards,
Karl
Don
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
--
Karl Pauls
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
--
Karl Pauls
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail:[email protected]
For additional commands, e-mail:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
