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?
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, 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]
