Blogs
I know some of you have been disappointed by my last post about discontinuing the Liferay 7.2 Community Beta Program. I understand. It was also hard for us to let it go. But I do believe there is much better way to have an open discussion with you other than setting time constraints and strict rules.
As you all know, Liferay Portal CE is an Open Source product developed in public. We want to make sure everyone feels welcome to contribute and influence its future at any point in time. And this is not something unique to us. Many, if not all, Open Source projects work this way. So we are not going to reinvent the wheel and will simply follow the established best practices.
That said, we need everyone to have full understanding of what the expectations and possibilities are during specific phases of the product release cycle.
Releases
All (since version 4.3.5) Liferay Portal CE releases are available at https://releases.liferay.com/portal/. Yes all, even those not meant for production use and those considered a “work in progress”. Below I will do my best to explain what is the purpose of different releases and how can you get involved.
Snapshots
Purpose: Mostly for internal purposes and provide immediate feedback to developers if the codebase is stable and likely to build.
How to recognize it: Snapshots are located in separate folder: https://releases.liferay.com/portal/snapshot-master/
What feedback we expect: No feedback is expected in general. However sometimes specific feedback on specific features may be requested early and community members may be pointed here instead of waiting for a milestone.
How to provide feedback: Please do not send feedback for snapshot releases unless explicitly requested. If specific feedback has been requested please follow the instructions provided.
How to report bugs: Please do not report bugs for snapshots releases. Those are considered work in progress and are expected to contain bugs and unfinished / not working functionalities.
Milestone releases
Purpose: The earliest releases of any new version providing early preview of the new and updated features. Their purpose is to demonstrate the progress made and to make it possible to provide early feedback on specific features that are mature enough.
How to recognize it: The release version number ends with Mn
where “n” is a number. For example “7.2.0 M2
”.
What feedback we expect: Each milestone release is accompanied by a blog post, providing specific information about the features that are mature enough and ready to receive feedback. You are welcomed to provide feedback on other features but keep in mind they may be still work in progress.
How to provide feedback: Please send feedback by posting in “Feedback for Milestone releases” forum category.
How to report bugs: Please do not report bugs for milestone releases. Those are considered work in progress and are expected to contain bugs and unfinished / not working functionalities. If you feel the release has introduced a regression bug, please raise your concerns in “Feedback for Milestone releases” forum category.
Alpha releases
Purpose: The first releases to be tested. The product is not yet feature complete.
How to recognize it: The release version number ends with An
where “n” is a number. For example “7.2.0 A1
”.
What feedback we expect: At this point feedback on all features and functionalities is welcomed.
How to provide feedback: Please send feedback by posting in “Feedback for Milestone releases” forum category.
How to report bugs: Please do not report bugs in new functionalities. Please report regression bugs in our issue tracking system. If unsure about the bug nature, please ask in “Feedback for Milestone releases”. Make sure to select the proper Alpha version. Please report bugs only related to the latest (at the time of reporting) Alpha version. Please do not report bugs in Alpha versions once Beta version is released.
Beta releases
Purpose: The first releases of a feature complete product. They may contain bugs and issues related to speed or performance.
How to recognize it: The release version number ends with Bn
where “n” is a number. For example “7.2.0 B1
”.
What feedback we expect: Feedback on all features and functionalities is welcomed. However as this is feature complete release, any feedback aiming to change or improve the features would be only considered for the next product version.
How to provide feedback: Please provide feedback in “Suggestions and Feature Requests” forum category.
How to report bugs: Please report bugs in our issue tracking system. Make sure to select the proper Beta version. Please report bugs only related to the latest (at the time of reporting) Beta version. Please do not report bugs in Beta versions once RC version is released.
Release Candidate releases
Purpose: Beta versions with potential to be a final product.
How to recognize it: The release version number ends with RCn
where “n” is a number. For example “7.2.0 RC1
”.
What feedback we expect: Feedback on all features and functionalities is welcomed. However as this is feature complete release, any feedback aiming to change or improve the features would be only considered for the next product version.
How to provide feedback: Please provide feedback in “Suggestions and Feature Requests” forum category.
How to report bugs: Please report bugs in our issue tracking system. Make sure to select the proper RC version. Please report bugs only related to the latest (at the time of reporting) RC version. Please do not report bugs in RC versions once GA version is released.
General Availability releases
Purpose: Stable, production ready product releases.
How to recognize it: The release version number ends with GAn
where “n” is a number. For example “7.2.0 GA1
”.
What feedback we expect: Feedback on all features and functionalities is welcomed. However as this is stable release, any feedback aiming to change or improve the features would be only considered for the next product version.
How to provide feedback: Please provide feedback in “Suggestions and Feature Requests” forum category.
How to report bugs: Please report bugs in our issue tracking system. Make sure to select the proper GA version. Please report bugs only related to the latest (at the time of reporting) GA version. Please do not report bugs in GA versions after the version’s end of life.
How we process feedback and bug reports
Both feedback related forum categories and issue tracking system have process in place to notify respective teams. In addition Developer Relations team is also actively monitoring those, trying to help bridge the gap when needed and minimize the duplication of the reports. In other words, we do our best to read, verify and respond to everything you have to say.
However we are all humans. Very busy humans in fact. So we may miss something or it sometimes may take a little longer than usual before you get a response. And yes, I'm aware of the amount of past feedback and reported issues are left without an answer. We have made our mistakes and we do learn from them. So if you feel your feedback or bug report is waiting too long, please send a friendly reminder in a form of new post, issue comment or an email to developer-relations@liferay.com