MyBB Community Forums

Full Version: MyBB 1.8.18 Pre-Release
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
(2018-08-13, 07:49 PM)Serpius Wrote: [ -> ]
(2018-08-13, 07:08 PM)Euan T Wrote: [ -> ]
(2018-08-13, 04:16 PM)effone Wrote: [ -> ]This is a version similar to main release, not meant to use in live sites but to distribute to mass for better testing and left out / newly introduced bugs fixing resulting to better normal release. Only difference is it doesn't contain any security patches included.

Don't know if I have described it correctly, but more or less its like that. After like a week of mass testing by the community the standard release with same version takes place adding identified bug fixes and security parches.

Exactly right. Pre-releases aren't posted on the blog and the normal extra work (eg: creating the version check pages, the new plugin hooks list, the release notes documentation) isn't done. Pre-releases are basically a way of us telling the world to expect a release soon (usually within a week of the first pre-release, so long as there aren't any big major issues discovered) and asking for the community to try and help us test the new packages if they can. It also gives theme and plugin developers a chance to make sure their products are compatible with the newest versions before they're even released.

That's fine, but...

I wondered about something...

What if those security releases cause some issues that were discovered in the public release? 

I am kind of thinking... well... if the pre-release had included the security fixes, then issues related to the security issues would be caught BEFORE the public release.

That's kind of where I am going with this.

Thoughts on this?

Including security patches in the pre-release would also mean publicising the security issues before there is a full proper patch available for them that is widely available and publicised on the blog (and as such the mailing list) which could cause those issues to be exploited before the full release.

We've started sharing the patches that we create with the users that report security issues now in an effort to add an extra pair of eyes to the patches (and to ensure we haven't mis-understood or not fully understood a report).
(2018-08-13, 04:16 PM)effone Wrote: [ -> ]This is a version similar to main release, not meant to use in live sites but to distribute to mass for better testing and left out / newly introduced bugs fixing resulting to better normal release. Only difference is it doesn't contain any security patches included.

Don't know if I have described it correctly, but more or less its like that. After like a week of mass testing by the community the standard release with same version takes place adding identified bug fixes and security parches.

Thanks for your response, this is a good step Smile
(2018-08-13, 09:10 PM)Euan T Wrote: [ -> ]
(2018-08-13, 07:49 PM)Serpius Wrote: [ -> ]
(2018-08-13, 07:08 PM)Euan T Wrote: [ -> ]
(2018-08-13, 04:16 PM)effone Wrote: [ -> ]This is a version similar to main release, not meant to use in live sites but to distribute to mass for better testing and left out / newly introduced bugs fixing resulting to better normal release. Only difference is it doesn't contain any security patches included.

Don't know if I have described it correctly, but more or less its like that. After like a week of mass testing by the community the standard release with same version takes place adding identified bug fixes and security parches.

Exactly right. Pre-releases aren't posted on the blog and the normal extra work (eg: creating the version check pages, the new plugin hooks list, the release notes documentation) isn't done. Pre-releases are basically a way of us telling the world to expect a release soon (usually within a week of the first pre-release, so long as there aren't any big major issues discovered) and asking for the community to try and help us test the new packages if they can. It also gives theme and plugin developers a chance to make sure their products are compatible with the newest versions before they're even released.

That's fine, but...

I wondered about something...

What if those security releases cause some issues that were discovered in the public release? 

I am kind of thinking... well... if the pre-release had included the security fixes, then issues related to the security issues would be caught BEFORE the public release.

That's kind of where I am going with this.

Thoughts on this?

Including security patches in the pre-release would also mean publicising the security issues before there is a full proper patch available for them that is widely available and publicised on the blog (and as such the mailing list) which could cause those issues to be exploited before the full release.

We've started sharing the patches that we create with the users that report security issues now in an effort to add an extra pair of eyes to the patches (and to ensure we haven't mis-understood or not fully understood a report).

Ok,  that makes sense. 

I had not known about that 'extra step' that was taken to share the patches with the users to assure that those patches do work (or not work).

Thanks for the clarification.
(2018-08-13, 03:03 AM)effone Wrote: [ -> ]For the php_info() error it appears that your host is blocking the functionality. It is required to remove phpinfo from the list of disabled functions in php.ini. Ask your host for further assistance regarding this.

phpinfo is a security nightmare. It should never be enabled on a production system.
(2018-08-14, 01:07 PM)Lunorian Wrote: [ -> ]
(2018-08-13, 03:03 AM)effone Wrote: [ -> ]For the php_info() error it appears that your host is blocking the functionality. It is required to remove phpinfo from the list of disabled functions in php.ini. Ask your host for further assistance regarding this.

phpinfo is a security nightmare. It should never be enabled on a production system.

And this is a pre-release and also shouldn't be enabled on a production system. What is your point?
... also, enabling or disabling PHP core functions doesn't come under MyBB scope.
Wanted to ask would there be too many things to change when trying to upgrade from .15 to .18 when you push .18?
If you skip versions in between it is always recommended to have a full upgrade instead of partial.
There are not too many things to do if you are using default theme. For a custom theme you need to go through the template changes (outlined in release notes) and do the modifications in your theme templates accordingly or ask the theme developer to update the theme for you (which is his job, actually).
For admin actions, there are clear guidelines to adhere in the merged pull request comments and / or in release notes. Such as:
https://github.com/mybb/mybb/pull/3216#i...-412369569
or
https://github.com/effone/effone.github....badword.md
(2018-08-21, 10:29 AM)effone Wrote: [ -> ]If you skip versions in between it is always recommended to have a full upgrade instead of partial.
There are not too many things to do if you are using default theme. For a custom theme you need to go through the template changes (outlined in release notes) and do the modifications in your theme templates accordingly or ask the theme developer to update the theme for you (which is his job, actually).
For admin actions, there are clear guidelines to adhere in the merged pull request comments and / or in release notes. Such as:
https://github.com/mybb/mybb/pull/3216#i...-412369569
or
https://github.com/effone/effone.github....badword.md

So I shouldn't be expecting mysql errors and php errors. That's great!
Any news about 1.8.18 release? Are there any known issue or issue which must be solved? I see no reports from testing of pre-release
Pages: 1 2 3 4