Project

General

Profile

Actions

Feature #6974

open

Define manually the versions order in Roadmap (when date isn't defined)

Added by Stéphane Klein over 13 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Roadmap
Target version:
-
Start date:
2010-11-25
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

Hi,

in my project, I've many versions in my Roadmap.

Actually version are ordered by date and by title.

In my project, I don't define release date, however I would like to define the versions order.

Is it possible to append this feature ?

Regards,
Stephane


Files

version-order.png (310 KB) version-order.png Sunding Wei, 2020-12-17 15:23

Related issues

Related to Redmine - Feature #6881: Version numbering sortNew2010-11-13

Actions
Related to Redmine - Feature #1137: Project versionClosed2008-04-29

Actions
Has duplicate Redmine - Feature #12814: Ability to specify target version sort orderReopened

Actions
Has duplicate Redmine - Feature #8080: Option for alphabetical only sorting of versions (date ignored)Closed2011-04-06

Actions
Has duplicate Redmine - Feature #13681: Option to choose sorting versions in roadmapClosed

Actions
Actions #1

Updated by Dipan Mehta about 11 years ago

+100. This is a very critical functionality.

Version name (automated) sorting has been an issue with debates and still there seems no universally accepted way. See related issues: #11153 vs. #12814. What is otherwise not reported but becomes even more mess when there are multiple projects sharing their versions across tree/hierarchy and none has a date for it!

Other related issues are: #6881, #7269, #8080

The trouble is, there won't ever be a one-fit-solution-for-all. I think best situation can be if the versions are allowed to be explicitly manually ordered on the versions page.

It doesn't take a genius to make it -but might ease everyone's problems.

+100 please implement this.

Actions #2

Updated by Daniel Albuschat over 10 years ago

+1 from me, too.
We use Versions as "Milestones" with descriptive texts, hence an alphabetical order is not useful to us.
We use redmine to plan our projects, too, and there are no due dates while planning.
This means that versions are in a totally useless order while planning a project, which is a real burden to the planner and makes it difficult to talk about a project in the planning phase based on the roadmap.

Actions #3

Updated by ixbidie ixbidie over 10 years ago

+1 too
joining my previous speakers

Actions #4

Updated by chu chu about 9 years ago

+1

I think most people want least version in top of the list, like
https://github.com/redmine/redmine/releases
or
http://jmeter-plugins.org/downloads/all/

If I made the PR, will you accept it?

Actions #5

Updated by Bryn Jeffries about 9 years ago

+1
Ideally this should be configurable, but by default the order should by according to the displayed text. I can get what I want by hacking app/models/version.rb to

  # Versions are sorted by name
  # then by effective date (nulls lose) and then id
  def <=>(version)
    if name == version.name
      if self.effective_date
        if version.effective_date
          self.effective_date == version.effective_date ? id <=> version.id : self.effective_date <=> version.effective_date
        else
          1
        end
      else
         -1
      end
    else
      name <=> version.name
    end
  end

Actions #6

Updated by nano devel over 7 years ago

+1

Actions #7

Updated by Klavs Klavsen over 6 years ago

Will this ever get accepted into redmine? I'm really missing it :(

Actions #8

Updated by Sunding Wei over 3 years ago

10 years later, I still need this feature desperately.

Actions #9

Updated by Sunding Wei over 3 years ago

I finally solved the roadmap versions sorting issue, see the screenshot, assume we always create bigger version each time.

The changed code of: app/models/version.rb

  def <=>(version)
    if self.effective_date
      if version.effective_date
        # both have dates
        if self.effective_date == version.effective_date
          # 1. (v0.1) to (v0.2)
          id <=> version.id
        else
          # 2. (early) to (later)
          self.effective_date <=> version.effective_date
        end
      else
        # 3. (date) to (no date)
        -1
      end
    else
      if version.effective_date
        # 4. (date) to (no date)
        1
      else
        # 5. both no dates, order by id descent
        version.id <=> id
      end
    end
  end

Actions #10

Updated by Holger Just over 1 year ago

Actions

Also available in: Atom PDF