Re: Time to start 4.1 planning?
2013/11/12 Rob Weir robw...@apache.org On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liuliush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. What about taking into account to keep the possibility to release a second Beta version? It can include fixes for the most nasty and prominent bugs. Well, hopefully we do some amount of testing before we have a beta. So the goal should be for the beta to have no nasty and prominent bugs. The beta is a form of insurance and a way of setting expectations. For example, I think these two scenarios are technically equivalent: a) release 4.1.0 after normal testing b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing. and a') release 4.1.0 beta after normal testing b') release 4.1.0 GA after fixing important bugs found in beta These are technically the same, and take approximately the same amount of time. The difference is in user expectations. A beta designation tells the cautious user to avoid it. It encourages users who are willing to take more risk and help us by giving feedback. It also helps preserve the brand reputation by ensuring that the actual GA releases are high quality. (If we're not careful the users will develop a sense to avoid all x.y.0 releases, believing them to be low quality. Other products have run into that problem, even with x.y.1 and x.y.2 releases. I think it is better if we can avoid having that kind of reputation.) A 2nd beta might be necessary in some rare cases, but I think in most cases we fix the critical bugs found in the beta and just do normal re-testing of those areas in a Release Candidate. Hi, Rob, I think a public beta is a good idea! After the 4.1 feature development and related FVT completed, I think we kick off a beta testing which cover the major function areas, then announce the 4.1 beta. Then we run the Full Regression Test and monitor the beta feedback, from 4.0 experience the Full Regression Test will take at least 4 weeks, depends on the number of volunteers. Then the end game critical fix and RC build testing for 4.1. - Shenfeng (Simon) Regards, -Rob If we agree on that, we should expand the timeframe to 6 or more weeks. My 2 ct. Marcus I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Time to start 4.1 planning?
Am 11/11/2013 10:33 PM, schrieb Rob Weir: On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liuliush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. What about taking into account to keep the possibility to release a second Beta version? It can include fixes for the most nasty and prominent bugs. Well, hopefully we do some amount of testing before we have a beta. So the goal should be for the beta to have no nasty and prominent bugs. The beta is a form of insurance and a way of setting expectations. For example, I think these two scenarios are technically equivalent: a) release 4.1.0 after normal testing b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing. and a') release 4.1.0 beta after normal testing b') release 4.1.0 GA after fixing important bugs found in beta Sure but we want to do a testing phase in public and not just technically. These are technically the same, and take approximately the same amount of time. The difference is in user expectations. A beta designation tells the cautious user to avoid it. It encourages users who are willing to take more risk and help us by giving feedback. It also helps preserve the brand reputation by ensuring that the actual GA releases are high quality. (If we're not careful the users will develop a sense to avoid all x.y.0 releases, believing them to be low quality. Other products have run into that problem, even with x.y.1 and x.y.2 releases. I think it is better if we can avoid having that kind of reputation.) Intersting, one can understand your arguments as points to *do* a second Beta release. ;-) A 2nd beta might be necessary in some rare cases, but I think in most cases we fix the critical bugs found in the beta and just do normal re-testing of those areas in a Release Candidate. Still no point not to do a second release. But before you go on with writting, please understand my suggestion as simple suggestion. I don't want to force it. When you deny it with a short post, then it's fine. No need to find many arguments that speak (maybe) against it. ;-) Marcus If we agree on that, we should expand the timeframe to 6 or more weeks. My 2 ct. Marcus I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Time to start 4.1 planning?
On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/11/2013 10:33 PM, schrieb Rob Weir: On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liuliush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. What about taking into account to keep the possibility to release a second Beta version? It can include fixes for the most nasty and prominent bugs. Well, hopefully we do some amount of testing before we have a beta. So the goal should be for the beta to have no nasty and prominent bugs. The beta is a form of insurance and a way of setting expectations. For example, I think these two scenarios are technically equivalent: a) release 4.1.0 after normal testing b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing. and a') release 4.1.0 beta after normal testing b') release 4.1.0 GA after fixing important bugs found in beta Sure but we want to do a testing phase in public and not just technically. These are technically the same, and take approximately the same amount of time. The difference is in user expectations. A beta designation tells the cautious user to avoid it. It encourages users who are willing to take more risk and help us by giving feedback. It also helps preserve the brand reputation by ensuring that the actual GA releases are high quality. (If we're not careful the users will develop a sense to avoid all x.y.0 releases, believing them to be low quality. Other products have run into that problem, even with x.y.1 and x.y.2 releases. I think it is better if we can avoid having that kind of reputation.) Intersting, one can understand your arguments as points to *do* a second Beta release. ;-) A 2nd beta might be necessary in some rare cases, but I think in most cases we fix the critical bugs found in the beta and just do normal re-testing of those areas in a Release Candidate. Still no point not to do a second release. But before you go on with writting, please understand my suggestion as simple suggestion. I don't want to force it. When you deny it with a short post, then it's fine. No need to find many arguments that speak (maybe) against it. ;-) I'm not necessarily opposed to have 2, or even 3 betas. (Ha!). But I say let the facts, not preconceptions, determine what we do. Let's do a beta, look at the results, discuss and then determine the next steps. I *predict* that only one beta will be needed. But I'm not insisting on it. Regards, -Rob Marcus If we agree on that, we should expand the timeframe to 6 or more weeks. My 2 ct. Marcus I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Time to start 4.1 planning?
Am 11/12/2013 10:36 PM, schrieb Rob Weir: On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/11/2013 10:33 PM, schrieb Rob Weir: On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liuliush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. What about taking into account to keep the possibility to release a second Beta version? It can include fixes for the most nasty and prominent bugs. Well, hopefully we do some amount of testing before we have a beta. So the goal should be for the beta to have no nasty and prominent bugs. The beta is a form of insurance and a way of setting expectations. For example, I think these two scenarios are technically equivalent: a) release 4.1.0 after normal testing b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing. and a') release 4.1.0 beta after normal testing b') release 4.1.0 GA after fixing important bugs found in beta Sure but we want to do a testing phase in public and not just technically. These are technically the same, and take approximately the same amount of time. The difference is in user expectations. A beta designation tells the cautious user to avoid it. It encourages users who are willing to take more risk and help us by giving feedback. It also helps preserve the brand reputation by ensuring that the actual GA releases are high quality. (If we're not careful the users will develop a sense to avoid all x.y.0 releases, believing them to be low quality. Other products have run into that problem, even with x.y.1 and x.y.2 releases. I think it is better if we can avoid having that kind of reputation.) Intersting, one can understand your arguments as points to *do* a second Beta release. ;-) A 2nd beta might be necessary in some rare cases, but I think in most cases we fix the critical bugs found in the beta and just do normal re-testing of those areas in a Release Candidate. Still no point not to do a second release. But before you go on with writting, please understand my suggestion as simple suggestion. I don't want to force it. When you deny it with a short post, then it's fine. No need to find many arguments that speak (maybe) against it. ;-) I'm not necessarily opposed to have 2, or even 3 betas. (Ha!). But I say let the facts, not preconceptions, determine what we do. Let's do a beta, look at the results, discuss and then determine the next Great, then you have understood what I wanted to say. Marcus steps. I *predict* that only one beta will be needed. But I'm not insisting on it. Regards, -Rob Marcus If we agree on that, we should expand the timeframe to 6 or more weeks. My 2 ct. Marcus I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Time to start 4.1 planning?
I just updated the 4.1 planning wiki[1]: (1) I added the section of Proposed Release Schedule, including the beta. But I left most of the milestones TBD. (2) I created a wiki page of AOO Feature Enhancement Backlog[2], and left only those active items (per my reading from the dev list) in 4.1, but moved the rest to this backlog. Any comments are welcome! [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Feature+Enhancement+Backlog - Shenfeng (Simon) 2013/11/13 Marcus (OOo) marcus.m...@wtnet.de Am 11/12/2013 10:36 PM, schrieb Rob Weir: On Tue, Nov 12, 2013 at 3:51 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/11/2013 10:33 PM, schrieb Rob Weir: On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liuliush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. What about taking into account to keep the possibility to release a second Beta version? It can include fixes for the most nasty and prominent bugs. Well, hopefully we do some amount of testing before we have a beta. So the goal should be for the beta to have no nasty and prominent bugs. The beta is a form of insurance and a way of setting expectations. For example, I think these two scenarios are technically equivalent: a) release 4.1.0 after normal testing b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing. and a') release 4.1.0 beta after normal testing b') release 4.1.0 GA after fixing important bugs found in beta Sure but we want to do a testing phase in public and not just technically. These are technically the same, and take approximately the same amount of time. The difference is in user expectations. A beta designation tells the cautious user to avoid it. It encourages users who are willing to take more risk and help us by giving feedback. It also helps preserve the brand reputation by ensuring that the actual GA releases are high quality. (If we're not careful the users will develop a sense to avoid all x.y.0 releases, believing them to be low quality. Other products have run into that problem, even with x.y.1 and x.y.2 releases. I think it is better if we can avoid having that kind of reputation.) Intersting, one can understand your arguments as points to *do* a second Beta release. ;-) A 2nd beta might be necessary in some rare cases, but I think in most cases we fix the critical bugs found in the beta and just do normal re-testing of those areas in a Release Candidate. Still no point not to do a second release. But before you go on with writting, please understand my suggestion as simple suggestion. I don't want to force it. When you deny it with a short post, then it's fine. No need to find many arguments that speak (maybe) against it. ;-) I'm not necessarily opposed to have 2, or even 3 betas. (Ha!). But I say let the facts, not preconceptions, determine what we do. Let's do a beta, look at the results, discuss and then determine the next Great, then you have understood what I wanted to say. Marcus steps. I *predict* that only one beta will be needed. But I'm not insisting on it. Regards, -Rob Marcus If we
Re: Time to start 4.1 planning?
On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu liush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. Regards, -Rob I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Time to start 4.1 planning?
On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liu liush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. Juergen Regards, -Rob I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Time to start 4.1 planning?
Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liuliush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. What about taking into account to keep the possibility to release a second Beta version? It can include fixes for the most nasty and prominent bugs. If we agree on that, we should expand the timeframe to 6 or more weeks. My 2 ct. Marcus I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Time to start 4.1 planning?
On Mon, Nov 11, 2013 at 3:21 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 11/11/2013 04:12 PM, schrieb Jürgen Schmidt: On 11/11/13 3:59 PM, Rob Weir wrote: On Mon, Nov 11, 2013 at 3:32 AM, Shenfeng Liuliush...@gmail.com wrote: Hi, all, It was one month since 4.0.1 release. And I noticed some some great works are going to be delivered soon. e.g. the IA2 framework from Steve, the Mac 64-bit support from Herbert, and Windows Patch mechanism from Andre. So I'm thinking, is it a good time to start the 4.1 plan now? We should deliver those great value to our users through a formal release ASAP! And IMO, even only the 3 items above can be enough for a release to be called 4.1. We also want to do OOXML improvement by integrating OSBA patches, and enhance user experience like in-place Input Field, and many other things... While, I think we can keep the continuous improvement across releases. From the record breaking download number since 4.0 and 4.0.1, I feel that keeping regular release is very important to response to our users, attract more new comers, and bring this product to success. So I suggest we start the 4.1 plan now, and set a target date. Since 4.0 was in July, 4.0.1 was in Oct, I feel some time in 1Q will be a good time for 4.1. Hi Simon, Something to think about: After 4.0.0 we discussed having a public beta with out next major release. If we think this is worth doing, then we should plan on two dates: 1) A public beta data, and 2) a final release date. For the beta to be useful I think we would want it to last 3-4 weeks, enough time to process any new bug reports, identify any critical regressions, and fix them. 4 weeks between both is a minimum form my pov But having a beta is of course the route we should take. What about taking into account to keep the possibility to release a second Beta version? It can include fixes for the most nasty and prominent bugs. Well, hopefully we do some amount of testing before we have a beta. So the goal should be for the beta to have no nasty and prominent bugs. The beta is a form of insurance and a way of setting expectations. For example, I think these two scenarios are technically equivalent: a) release 4.1.0 after normal testing b) release 4.1.1 to fix major bugs that we missed in 4.1.0 testing. and a') release 4.1.0 beta after normal testing b') release 4.1.0 GA after fixing important bugs found in beta These are technically the same, and take approximately the same amount of time. The difference is in user expectations. A beta designation tells the cautious user to avoid it. It encourages users who are willing to take more risk and help us by giving feedback. It also helps preserve the brand reputation by ensuring that the actual GA releases are high quality. (If we're not careful the users will develop a sense to avoid all x.y.0 releases, believing them to be low quality. Other products have run into that problem, even with x.y.1 and x.y.2 releases. I think it is better if we can avoid having that kind of reputation.) A 2nd beta might be necessary in some rare cases, but I think in most cases we fix the critical bugs found in the beta and just do normal re-testing of those areas in a Release Candidate. Regards, -Rob If we agree on that, we should expand the timeframe to 6 or more weeks. My 2 ct. Marcus I suggest to update the 4.1 planning wiki[1] and: (1) Set the target date. (2) Clean up the planning list, starting from leaving only the active items, and moving the rest to project backlog[2]. Any suggestion/comments? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Blog - Shenfeng (Simon) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
