Making versions more meaningful across projects

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Making versions more meaningful across projects

mojavelinux
Administrator
As I mentioned in the release notes for 0.1.4, we're shifting the version numbering in the next release of Asciidoctor core so we can leverage all the parts (major, minor and micro). That's why the next release will be 1.5.0.

To help users better understand which version of a subproject, such as AsciidoctorJ or one of the build plugins, goes with Asciidoctor core, I'd like to encourage those projects make the switch as well.

Here's how I'm thinking we should align.

. If the major version is different between core and another project, the user should not expect that they work together (though, they may).

. We recommend that at least the minor version match. Projects should not increment their minor version ahead of core, as this gives the impression there is a newer core available.

. The user should not infer any relationship between micro versions across projects. That position is entirely up to the project to increment at will. However, the project should ensure to maintain capability with the major + minor version of core when doing so.

The goal is to release core often enough that a project should never feel stuck on a minor version. If anything, core should keep a pace ahead of the projects so that the projects always have something to move towards.

These are just suggestions and voluntary. It's up to you guys. I'm proposing this alignment to help users feel confident about which versions of the libraries to select.

wdyt?
Reply | Threaded
Open this post in threaded view
|

Re: Making versions more meaningful across projects

LightGuardjp
Administrator
Theory sounds good, the actual practice of it (speaking for myself and my time available to put in, I'm not SuperMan like Dan and can pull 20 hour days) may not be as rosy or as quick paced.


On Wed, Nov 6, 2013 at 6:00 PM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
As I mentioned in the release notes for 0.1.4, we're shifting the version numbering in the next release of Asciidoctor core so we can leverage all the parts (major, minor and micro). That's why the next release will be 1.5.0.

To help users better understand which version of a subproject, such as AsciidoctorJ or one of the build plugins, goes with Asciidoctor core, I'd like to encourage those projects make the switch as well.

Here's how I'm thinking we should align.

. If the major version is different between core and another project, the user should not expect that they work together (though, they may).

. We recommend that at least the minor version match. Projects should not increment their minor version ahead of core, as this gives the impression there is a newer core available.

. The user should not infer any relationship between micro versions across projects. That position is entirely up to the project to increment at will. However, the project should ensure to maintain capability with the major + minor version of core when doing so.

The goal is to release core often enough that a project should never feel stuck on a minor version. If anything, core should keep a pace ahead of the projects so that the projects always have something to move towards.

These are just suggestions and voluntary. It's up to you guys. I'm proposing this alignment to help users feel confident about which versions of the libraries to select.

wdyt?



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Making-versions-more-meaningful-across-projects-tp961.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Reply | Threaded
Open this post in threaded view
|

Re: Making versions more meaningful across projects

mojavelinux
Administrator

Jason,

I don't expect it to require extra effort. It's just a proposal to select version numbers with purpose. The main shift is really at the major and minor level. If we switch to 1.x.x, we give ourselves more room for versions. If we agree to use the minor number to track the core library version (e.g., 1.5.x) then things just make a lot more sense.

I'm not trying to push projects to go faster or slower, just to align on version numbers in a sensible way. Hopefully that clarifies the goal a bit.

-Dan

On Nov 7, 2013 10:19 AM, "LightGuardjp [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
Theory sounds good, the actual practice of it (speaking for myself and my time available to put in, I'm not SuperMan like Dan and can pull 20 hour days) may not be as rosy or as quick paced.


On Wed, Nov 6, 2013 at 6:00 PM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
As I mentioned in the release notes for 0.1.4, we're shifting the version numbering in the next release of Asciidoctor core so we can leverage all the parts (major, minor and micro). That's why the next release will be 1.5.0.

To help users better understand which version of a subproject, such as AsciidoctorJ or one of the build plugins, goes with Asciidoctor core, I'd like to encourage those projects make the switch as well.

Here's how I'm thinking we should align.

. If the major version is different between core and another project, the user should not expect that they work together (though, they may).

. We recommend that at least the minor version match. Projects should not increment their minor version ahead of core, as this gives the impression there is a newer core available.

. The user should not infer any relationship between micro versions across projects. That position is entirely up to the project to increment at will. However, the project should ensure to maintain capability with the major + minor version of core when doing so.

The goal is to release core often enough that a project should never feel stuck on a minor version. If anything, core should keep a pace ahead of the projects so that the projects always have something to move towards.

These are just suggestions and voluntary. It's up to you guys. I'm proposing this alignment to help users feel confident about which versions of the libraries to select.

wdyt?



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Making-versions-more-meaningful-across-projects-tp961.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Making-versions-more-meaningful-across-projects-tp961p965.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Making versions more meaningful across projects

LightGuardjp
Administrator
Must have read things wrong. Or my over stressed brain read more into it than was there. 

Sent from my iPhone

On Nov 7, 2013, at 16:00, "mojavelinux [via Asciidoctor :: Discussion]" <[hidden email]> wrote:

Jason,

I don't expect it to require extra effort. It's just a proposal to select version numbers with purpose. The main shift is really at the major and minor level. If we switch to 1.x.x, we give ourselves more room for versions. If we agree to use the minor number to track the core library version (e.g., 1.5.x) then things just make a lot more sense.

I'm not trying to push projects to go faster or slower, just to align on version numbers in a sensible way. Hopefully that clarifies the goal a bit.

-Dan

On Nov 7, 2013 10:19 AM, "LightGuardjp [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
Theory sounds good, the actual practice of it (speaking for myself and my time available to put in, I'm not SuperMan like Dan and can pull 20 hour days) may not be as rosy or as quick paced.


On Wed, Nov 6, 2013 at 6:00 PM, mojavelinux [via Asciidoctor :: Discussion] <[hidden email]> wrote:
As I mentioned in the release notes for 0.1.4, we're shifting the version numbering in the next release of Asciidoctor core so we can leverage all the parts (major, minor and micro). That's why the next release will be 1.5.0.

To help users better understand which version of a subproject, such as AsciidoctorJ or one of the build plugins, goes with Asciidoctor core, I'd like to encourage those projects make the switch as well.

Here's how I'm thinking we should align.

. If the major version is different between core and another project, the user should not expect that they work together (though, they may).

. We recommend that at least the minor version match. Projects should not increment their minor version ahead of core, as this gives the impression there is a newer core available.

. The user should not infer any relationship between micro versions across projects. That position is entirely up to the project to increment at will. However, the project should ensure to maintain capability with the major + minor version of core when doing so.

The goal is to release core often enough that a project should never feel stuck on a minor version. If anything, core should keep a pace ahead of the projects so that the projects always have something to move towards.

These are just suggestions and voluntary. It's up to you guys. I'm proposing this alignment to help users feel confident about which versions of the libraries to select.

wdyt?



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Making-versions-more-meaningful-across-projects-tp961.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Making-versions-more-meaningful-across-projects-tp961p965.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Making-versions-more-meaningful-across-projects-tp961p967.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Making versions more meaningful across projects

asotobu
What Dan sounds good to me. I will try to move as long as Asciidoctor in AsciidoctorJ, but of course sometimes a new bug, or something could be discovered, and then micro part could be used to fix it.

From AsciidoctorJ point of view it is ok.

+1