Skip to content

Commit

Permalink
major releases should increse the major version number
Browse files Browse the repository at this point in the history
  • Loading branch information
@kraih
kraih committed Apr 2, 2012
1 parent aae0c8e commit f5c22db
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions lib/Mojolicious/Guides/CodingGuidelines.pod
View file
Expand Up @@ -63,8 +63,8 @@ depends on it.
New features can be marked as experimental to be excluded from deprecation
policies.

A major release can be version number independent and is signaled by a new
unique code name based on a unicode character.
A major release is signaled by a new major version number and a unique code
name based on a unicode character.

Only add prereqs if absolutely necessary and make them optional if possible.

Expand Down Expand Up @@ -97,7 +97,7 @@ is optional if it doesn't increase readability.
Every file should contain at least one quote from C<The Simpsons> or
C<Futurama>.

No names outside of the CREDITS section of Mojo.pm.
No names outside of C<Mojolicious.pm>.

No Elitism.

Expand Down

2 comments on commit f5c22db

@yuki-kimoto
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This rule is easy to understand for users. but Mojolicious is yet young, so you want to add and change many features.
Major number maybe increase one or two in a year.

2.01
3.01
4.01
5.01
6.01

I think it is good to use major version for other purpose (for example, for much bigger change),

Version number can't decrease in CPAN.

@kraih
Copy link
Member Author

@kraih kraih commented on f5c22db Apr 3, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Major release once or twice per year is the plan.

Please sign in to comment.