I'm looking for a part-time remote job.

Hire me


I'm the author of:

Mastering Redmine is a comprehensive guide with tips, tricks and best practices, and an easy-to-learn structure.

Check the book's project or

Buy the book

Social pages of the book:

By buying this book you also donate to Redmine (see this page).


Follow me:

Announcement about Redmine < 1.4.x and ChiliProject < 3.x

Many of you, perhaps, wondered why I supported such old Redmine versions as 1.0.x? The answer is simple: cause I used (and still do) Redmine 1.0.1!.. But why?..

I used to work as a Linux system administrator, so I know, what is the security and how important is to have a well tested and well maintained installation. For this reason I chose Debian as my server platform. Debian is, however, known to have outdated package versions… But there is a reason why it happens. Debian has three “branches”: unstable, testing and stable. To get into the stable branch a package needs to pass the unstable branch, where it gets tested, and wait for a release in the testing branch, where the whole system gets tested once again.

But why other Linux distros use the latest versions then?.. Others rely on authors’ opinion, whether a package is stable. And Debian guys prefer to check this themselves.

The release of Debian happens not too often. When the testing branch gets released and becomes stable, the versions of the packages in this branch get “frozen”, that is, only minor fixes (usually security fixes) can be put into these packages. Therefore their versions can’t change much! Thus, till this moment Debian shipped with Redmine 1.0.x. That’s why I’m still using this version.

You can ask why didn’t I installed Redmine from sources. My answer is: If you do this, you must further care about security fixes by yourself, i.e., not relying on the Debian team! To be able to do this you must: a) check security news for Redmine, b) manually update it each time new version is released, c) ensure Redmine does not get broken, when you update the system, d) ensure the system does not get broken, when you update Redmine, e) ensure Redmine won’t become vulnerable due to changes in the system, and so on. If something requires you to spend much time for it and it’s not your main job, most likely, you will fail…

For this reason I use Redmine 1.0.x which ships with Debian and for these reasons I support 1.0.x!

But it happens, that new Debian version comes. Some time before this post (a long time, actually) the testing branch got frozen… And it is frozen right now! So the release is going to happen soon! Redmine version, which will come with new Debian, should be 1.4.x. So as soon as it happens and as soon as I upgrade my server I will stop supporting versions prior to 1.4.x. Good news is that, usually, I wait some time before doing upgrade. Not sure how much time it will be this time though. Also only the next release of the project, after I have upgraded my server to new Debian, will drop older versions support and I will mention this explicitly on the project overview page and in news.

Meanwhile, however, I’m going to drop support for Redmine 1.1.x, 1.2.x and 1.3.x, as it is really too many versions to test plugins on!

Now regarding ChiliProject…

ChiliProject is not yet available in Debian, so I’m not even considering to use it. Why?.. As I have written above, because it’s easier to use Debian packages and maintain them, that is, for the same reason, that I don’t use the recent Redmine. And to make my projects support easier I also decided not to test them under ChiliProject 2.x. What, however, does not mean, that they won’t work with ChiliProject 2.x, this just means, that I won’t check this. Sorry.

Anyway you can still report bugs related to Redmine prior to 1.4.x. and ChiliProject prior to 3.x. Will try to fix them.

 

Comments

Also available in: Atom

Add a comment