I don't think there is a timetable; there is this: https://git.ispconfig.org/ispconfig/ispconfig3/milestones/47
And when you select the bugs then you can see that there are still some relevant issue to be fixed before we can release it. Or do you want to use ispconfig witout working SSH users?
I see your point your trying to make, but you should remember their are other thing that need to be done at the same time like the ispconfig3 manual getting updated, and tutorials etc. so its will take some time. I am hoping that it will be ready in time for the Ubuntu 16.04 LTS release on the 21st of this month, but its take as long as its takes, the main thing is that it is almost done.
The milestones track the features requests and not the bugs that have not been assigned to a release yet. So according to you, a non working SSH user is a new feature that we shall include in the next release?
Btw. with the next releases we will switch to fixed release schedule. This means that the software gets released in April and October each year with a new major version. So you will get the 3.2 version in October 2016.
My question was and the answer was: Ehm.. no? Sorry I really don't get it. Of course I'd suspect the status to be set back to 90%, adding the open tickets/bugs to the milestone, but maybe I am just not able to filter the tickets / open issues here. How can I see what tickets still have to be solved for the next version?
You're likely using the milestone list fine, there simply aren't issues created for every bug that remains; many of them are simply fixed as they are found, and show up in the commit history but not the list of issues, and certainly not as an open issue if they're fixed immediately, so showing 100% completion (ie. no open issues) makes sense. The switch to gitlab issue tracking is pretty new, I suspect the workflow and consistency there will improve with time (eg. the next release).
The issue workflow in most cases is this: 1) Someone reports an issue. This does not mean that there is a bug as also many config problems of servers are reported as issues. 2) The next step is that one of the developers has to reproduce the issue and decide in which release it shall get fixed. In most case. In this step it would be possible to set a milestone for this issue. BUT, in most cases, the issue is fixed right away by the developer that reproduced it. So what happens then, the issue gets assigned a milestone, a fix gets pushed to git and the issue gets closed, all within a minute or two. So this issue will show up for 1-2 minutes in the pending issues list for this milestone and then gets moved to the closed issues list and if you dont view the tracker in these 2 minutes, you wont notice it. You will just see it in the activity list. So as you can see, it does not make sense to have an issue list for the public which is assigned to a milestone as this would require that we delay the bugfixes artificially or in other words, we reproduce them, assign them and then refuse to fix them. I guess that's not what you or others may want that we stop fixing bugs. Like I explained already above, the milestone list makes sense for new features but not for bugs as we can neither list unconfirmed issues which are no bugs as bugs nor can we list bugs that have not been found yet nor makes it sense to delay bug fixing just for the reason that you can see some items in the list. If you want to know what's going on, then take a look at the activity list. The developers know which bugs need to be fixed and when you are actively involved in development and tests daily then you would know that too. Just believe us, we will release the software when we feel that it is ready and we will announce that in the blog, at twitter, facebook and the newsletter as usual. This date will not be earlier or later if there is a list somewhere. I can add some nonsense records in the roadmap that I delete on the release day so you all see something there in the list, but is that really necessary? And btw, what do you think that you can estimate by looking at such a list? A single item can take 2 months to implement or 5 minutes, so without knowing the exact code and technical complications of an issue, you can not even estimate a date from a milestone list. There can be 10 issues in the list that get fixed in an hour before the release and there can be 1 issue that holds up the release for a few months.
Is the ISPConfig 3.1 Beta upgradable to final ISPConfig 3.1? I mean if I install the beta, will I be able to upgrade to the stable version when it will be publeshed? Regards, L.
