Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No way to know which version of moonmoon you have installed #30

Open
pascalchevrel opened this issue Mar 12, 2012 · 5 comments · May be fixed by #115
Open

No way to know which version of moonmoon you have installed #30

pascalchevrel opened this issue Mar 12, 2012 · 5 comments · May be fixed by #115
Labels
feature-request
Milestone
9.0.0

Comments

@pascalchevrel
Copy link
Contributor

There is currently no indication (either in the source code or visible via the administration UI) to know which version of Moonmoon you are using, that means that you don't know if you are currrent.

I think that the next version of moonmoon should expose this information in the admin console, we could even put in place a web service in the future to compare the installed version with the latest version and inform the user if he is outdated.

I don't know where this data should be stored, probably among the admin files. Dotclear puts the version number in the admin console as part of the window title, that's also a way to expose it.

Thoughts?
@pascalchevrel
Copy link
Contributor Author

I hadn't noticed the VERSION file at the root, so this information is available in the source code but it is not exposed/used in the application itself.

The version format ciurrently is:
moonmoon-8.12

I think we can drop the moonmoon- part, this is redundant in the context of the applicagtion itself and if we want to parse the version number for version checking, it means an extra step removing that part.

Do you have a preferred numbering scheme?

We could use for example:
major.minor for releases
major+1.dev for trunk

That would mean that the current master branch could be 9.dev and we release a new version it will be 9.0 and we update master to be 10.dev, if there is a minor release needed for a security issue or minor features/bug fixes backported from the dev branch, we can have a 9.1 release.

What do you think?

(BTW, I think you should set up a branch for the 8.12 version to archive the release history of the project)

@mauricesvay
Copy link
Member

I agree on removing the prefix in the VERSION file.

For now, the numbering scheme is similar to Ubuntu: year.month (yeah, 8.12 is very old).

@pascalchevrel
Copy link
Contributor Author

Would it be ok to change the version number on master from moonmoon-8.12 to 12.04dev? (to avoid having people cloning master and thinking they downloaded 8.12)

@mauricesvay
Copy link
Member

dev might be enough. Otherwise, we would have to update the version every month.

@pascalchevrel pascalchevrel mentioned this issue Apr 23, 2012
Merged
@samwilson
Copy link
Contributor

There's also the option of switching to http://semver.org/ format.

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Although I guess this has been resolved now anyway... :)

@ghost ghost modified the milestone: 9.0.0 May 10, 2017
@ghost ghost added the feature-request label May 10, 2017
rdalverny added a commit to rdalverny/moonmoon that referenced this issue Jan 5, 2022
@rdalverny
Add version info in admin page
303d6b5 
This adds version information in the administration area, with a hint towards possible new releases.

Helps moonmoon#30.

Should the version also appear in the public signature at the signature of the index page?
@rdalverny rdalverny linked a pull request Jan 5, 2022 that will close this issue
Open
@JavGuerra JavGuerra mentioned this issue Jan 28, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-request
Projects
None yet
Milestone
9.0.0
Development

Successfully merging a pull request may close this issue.

Add version info in admin page rdalverny/moonmoon
3 participants
@samwilson @mauricesvay @pascalchevrel