That can be decided when migrations are merged, depending on how points 2-4 are coming along at the time.
If migrations are finished and 2-4 are still in progress, we can declare alpha 1 the feature freeze point and all PRs would have to be done before then. As 2-4 get fixed, PRs are fixed.
If 2-4 are finished and migrations are not, as soon as migrations are done we can potentially release alpha 1. If this happens, instead of waiting to release alpha 1 due to open PRs we can immediately release alpha 1 and release alpha 2 on a timer 2-4 weeks later with whatever PRs are merged by then, with alpha 2 becoming the feature freeze point.
There may be value in having a repeat of the last feature freeze shortly after migrations are merged. The intent is to get everyone to declare what they want to be included in 3.1, and with migrations merged we could actually proceed with the freeze correctly. This will also eliminate someone opening a PR 2 weeks into 3 week period.
phpBB 3.1 Information and Status
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Re: phpBB 3.1 Information and Status
4. https://github.com/naderman/phpbb3-example-ext
7. I think events should be added at ANY stage (inc. maintenance releases). They cannot break anything and if an author gets an idea for an extension (or doesn't post the request before the RC), saying we cannot add an event until the next major release is ridiculous, nevermind saying that it can't even go into the next major release as it has already hit RC and I'm sure the MOD Team would strongly agree with this.
7. I think events should be added at ANY stage (inc. maintenance releases). They cannot break anything and if an author gets an idea for an extension (or doesn't post the request before the RC), saying we cannot add an event until the next major release is ridiculous, nevermind saying that it can't even go into the next major release as it has already hit RC and I'm sure the MOD Team would strongly agree with this.
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
Re: phpBB 3.1 Information and Status
Events can be added in maintenance releases but probably not during RC phase.
Re: phpBB 3.1 Information and Status
RC releases for x.y releases are very different to x.y.z RCs. For 3.0 we even provided support and allow submissions of contributions for RCs. I still think that new events should be addable at any stage as theoretically, they cannot cause bugs unless they have syntax errors or are overides. The latter wouldn't be allowed. Syntax errors would be picked up when the merger tests it.
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
Re: phpBB 3.1 Information and Status
Providing support and accepting cdb contributions does not add code to the tree and therefore cannot introduce bugs. Adding events may introduce bugs. The obvious issue is with php events which most of the time modify surrounding code. Template events are less of an issue because they tend to only affect themselves. Even so, the exact event name and location are supposed to be thought through and getting those wrong creates a bug of sorts. Php events that are in code which is not covered by the test suite can break at any time without anyone noticing.
I haven't been around when 3.0 was released but it sounds like 3.0 RCs were not really RC quality. Hopefully tree quality is higher now and 3.1 RCs can actually be RCs.
At the end of the day we can make individual exceptions, and we can also revisit this issue when beta 1 is released and again when RC 1 is released, but overall my feeling is RC releases should not be expected to add functionality.
---
On the topic of extension authors needing their events. I would prefer to iterate more frequently with 3.1.x releases, for example starting on 3.1.1 release 3 months after 3.1 is released.
If my event doc proposal is accepted it should be very easy to see what events are pending in (each) development version.
I haven't been around when 3.0 was released but it sounds like 3.0 RCs were not really RC quality. Hopefully tree quality is higher now and 3.1 RCs can actually be RCs.
At the end of the day we can make individual exceptions, and we can also revisit this issue when beta 1 is released and again when RC 1 is released, but overall my feeling is RC releases should not be expected to add functionality.
---
On the topic of extension authors needing their events. I would prefer to iterate more frequently with 3.1.x releases, for example starting on 3.1.1 release 3 months after 3.1 is released.
If my event doc proposal is accepted it should be very easy to see what events are pending in (each) development version.
Re: phpBB 3.1 Information and Status
seeing as the last activity I see is from 16 months ago (unless I am missing something on github) and seeing as, doing a search on Nils posts, he last visited/posted in this forum on Nov 12th 2012...good luck with that.Oleg wrote:1. We still need migrations (RFC). Since Nils insists on keeping the diff huge migrations are all on him.
Do not hire Christian Bullock he won't finish the job and will keep your money
Re: phpBB 3.1 Information and Status
https://github.com/phpbb/phpbb3/pull/1067 - 6 days ago?RMcGirr83 wrote:seeing as the last activity I see is from 16 months ago (unless I am missing something on github) and seeing as, doing a search on Nils posts, he last visited/posted in this forum on Nov 12th 2012...good luck with that.Oleg wrote:1. We still need migrations (RFC). Since Nils insists on keeping the diff huge migrations are all on him.
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
Re: phpBB 3.1 Information and Status
I was actually looking at the one from the first post in the link provided by Oleg which would be this one
https://github.com/phpbb/phpbb3/pull/527
Silly me eh?
https://github.com/phpbb/phpbb3/pull/527
Silly me eh?
Do not hire Christian Bullock he won't finish the job and will keep your money
- imkingdavid
- Registered User
- Posts: 1050
- Joined: Thu Jul 30, 2009 12:06 pm
Re: phpBB 3.1 Information and Status
Thanks for pointing that out. Looks like when the previous pull request was closed, the RFC was not updated. I have updated it now.RMcGirr83 wrote:I was actually looking at the one from the first post in the link provided by Oleg which would be this one
https://github.com/phpbb/phpbb3/pull/527
Silly me eh?
- imkingdavid
- Registered User
- Posts: 1050
- Joined: Thu Jul 30, 2009 12:06 pm
Re: phpBB 3.1 Information and Status
I can agree to that.Oleg wrote:That can be decided when migrations are merged, depending on how points 2-4 are coming along at the time.
If migrations are finished and 2-4 are still in progress, we can declare alpha 1 the feature freeze point and all PRs would have to be done before then. As 2-4 get fixed, PRs are fixed.
If 2-4 are finished and migrations are not, as soon as migrations are done we can potentially release alpha 1. If this happens, instead of waiting to release alpha 1 due to open PRs we can immediately release alpha 1 and release alpha 2 on a timer 2-4 weeks later with whatever PRs are merged by then, with alpha 2 becoming the feature freeze point.
There may be value in having a repeat of the last feature freeze shortly after migrations are merged. The intent is to get everyone to declare what they want to be included in 3.1, and with migrations merged we could actually proceed with the freeze correctly. This will also eliminate someone opening a PR 2 weeks into 3 week period.