On 10/8/09 2:09, Don Brown wrote:
I'd be happy to maintain 2.0.x for what will likely be a while, as
upgrading frequently just isn't an option for us. What about getting
access to the tck? With no committed unit or functional tests, making
changes is a very risky proposition. Is the tck something only
committers get access to? Could it be put into our build?
We are working on getting access to the TCK for committers, but that
isn't finalized yet. It is not clear what the precise terms will be. I
also started created some of my own framework tests, so perhaps we could
get an effort around creating more for ourselves. The TCK, while better
than nothing, isn't as thorough as you might expect.
As far as "promising" releases, I don't really think it has to be that
formal. If the Felix community needs to support older versions, why
not bring them into the fold and make them official? Apache is about
building the community so we should let the community shape its
direction. For example, in Struts, we still have committers using
Struts 1. A year or so ago, some folks wanted a 1.4 so they did the
work and released it, despite everyone else having moved on to Struts
2, so anyone is free to fix issues and do releases as needed. The
stability and support for Struts 1 is one of the key, if not the
primary, reasons it was so successful. If Felix is just a research
project, that's one thing, but if it meant to be embedded into
production systems, and the committers are its main customers, I don't
see any reason it shouldn't be maintained as such.
Thanks for re-evaluating this as it would remove a huge stumbling block for us,
While I don't necessarily agree with the implication that free long-term
support is required from the Felix community to make the project less
than a research avenue (you certainly have companies within the
community that would offer you support for a fee), I certainly think we
can have an integrated option for community members who volunteer for
maintaining a branch.
However, as you point out by only volunteering to maintain 2.0.x, we
cannot offer a blanket long-term strategy. And even for 2.0.x, once you
move onto something else, it is quite possible that there will be no
more long-term support for it. That is really the point we were trying
to make in the first place.
So, once 2.2.0 is out and 2.0.x goes into mothballs as far as mainline
development goes, then we just need to wait for the first issue to arise
and we can set this plan into motion. Until then, please keep posting
any issues so they can be integrated in a service release or the next
release.
We look forward to the new level of collaboration.
-> richard
Don
On Thu, Oct 8, 2009 at 2:26 AM, Richard S. Hall<[email protected]> wrote:
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]
---------------------------------------------------------------------
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]
