ISPConfig 3.1.16 becomes ISPConfig 3.2

Discussion in 'Developers' Forum' started by till, Jul 23, 2020.

  1. till

    till Super Moderator Staff Member ISPConfig Developer

    We decided to rename the upcoming 3.1.16 release to 3.2 to make it more clear that the next release is not just a small bugfix release. The release will contain many improvements and some of the changes have the potential to cause issues on very old systems and with this higher version number, we want to make users aware of that.
     
    elmacus, branov, ahrasis and 2 others like this.
  2. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    Shall the "stable-3.1" label be renamed to "stable-3.2" aswell?
     
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    We will make a new branch where the 3.2.x released get developed in.
     
    budgierless and ahrasis like this.
  4. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Seems appropriate; I've not mentioned it, but thought for some time that the larger/several year plans for 3.2 would better fit a major release number, 4.x
     
  5. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    I meant the label we add to feature requests and bugs that are scheduled to work on for the stable release ;)
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    ah, ok :) Yes, sure, this needs to be changed.
     
  7. budgierless

    budgierless Member

    hi, just wondering will the new user manual be released the same time as 3.2 or just before?
     
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    I will start working on a new manual when 3.2 is finished, so it will be release after 3.2 release. You will find a notice in the ISPConfig blog when it becomes available.
     
    Th0m, budgierless and ahrasis like this.
  9. Ruben Herold

    Ruben Herold New Member

    Is there any plan how long it would need to release 3.2 now?
    I plan installation and my distribution is centos8 as far as I know it will be supported with 3.2
     
  10. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

  11. Ruben Herold

    Ruben Herold New Member

    Thx for the fast feedback
     
  12. TonyG

    TonyG Active Member

    I'm eager to get started with 3.2 as well. As a noob I need to learn 3.1 fundamentals, but it doesn't make much sense for me to get too familiar with 3.1 details if they are going to change in a matter of days.

    As a Product Manager for other software products, and former QA Manager coordinating Betas, I have a recommendation/request. As a noob here I don't know what you publish for a new minor release, so please forgive if you already follow these practices.

    Please ensure that the documentation for the new features is robust so that Beta sites know exactly what has changed and what needs to be tested. Take an extra couple days for nothing but docs before the Beta. Changelogs for software are often sparse, with one line to indicate a change that was made. This compels each reader to go to the issue tracker to get more information, or to post in the forum to ask what is involved. Changes are often implemented with a number of UI assets (buttons, selections, workflow, etc) and none of this is documented prior to a "full" production release. This leaves Beta sites asking a lot of fundamental questions, which eventually gets incorporated into docs. But it would be much better to publish that info for the Betas, to avoid wasting time for everyone. This also helps to ensure that new features are tested better, allowing for pre-production rework rather than post-production efforts to help sites that might be crippled by some detail that wasn't tested in Beta.

    Again, please forgive, I'm speaking with decades of experience in this area. Somewhere between zero formal process and rigid formalities is a process that every project like this can and should follow. I'm eager to see how things go here, and happy to help improve these processes if requested.

    Thanks!
     
    Jesse Norell likes this.
  13. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    There are a lot of changes, but nothing big like a new interface. You can see the changes in the GitLab (https://git.ispconfig.org/ispconfig/ispconfig3/-/milestones/68)

    We will change the documentation, but I have some ideas about improvement which we will discuss when 3.2 is done.
     
    elmacus and TonyG like this.
  14. till

    till Super Moderator Staff Member ISPConfig Developer

    In fact, ISPConfig 3.2 works in the exact same way that 3.1 works, 3.2 just supports new operating systems and changes things under the hood, which the end-user won't notice or know anyway. There are some new checkboxes and settings of course, but none of them are necessary to use ISPConfig and most of them are fairly self-explaining. E.g. backup options are added so that you can choose between backup formats or in other words, if you select tar.gz instead of zip, you'll get a tar.gz and not a zip file :) So if you want to become familiar with ISPConfig 3.2, start becoming familiar with 3.1.

    There are no additional docs needed to use or try out the beta and we will not delay the beta release for months to write docs first.

    If you want to help to improve docs when 3.2 beta is out, then this is very welcome of course.
     
    budgierless, TonyG and Th0m like this.
  15. exynenem

    exynenem Member

    I have a question regarding the beta: Is the current stable-3.1 branch in feature-freeze? Otherwise I may have one more thing to commit to the code base.
     
  16. till

    till Super Moderator Staff Member ISPConfig Developer

    You can always make new merge requests against stable-3.1 branch. Depending on what the feature is, we will decide then if it gets into 3.1 or 3.2.1. We changed development a bit, we use branches now. So the steps are:

    1) Create a branch for your feature or issue, based on stable-3.1
    2) implement the changes in that new branch.
    3) make a merge request from your branch against stable-3.1. We will review it then, discuss changes if needed and decide in which release it fits bets.
     
  17. till

    till Super Moderator Staff Member ISPConfig Developer

    Just as info: I'm not able to finish the 3.2 beta today, additional problems popped up when using ISPConfig on a MySQL 8 system. I'll have to fix that on Monday before the beta can get released.
     
  18. exynenem

    exynenem Member

    Alright, thank you. I'am fully aware of the process of committing code to ISPConfig since it is not my first contribution.
    I'll try to schedule my other commits for 3.2.1 because I think I'm not gonna make it before the release of the beta version.
     
    till likes this.
  19. till

    till Super Moderator Staff Member ISPConfig Developer

Share This Page