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]
