You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Paul Benedict (JIRA)" <ji...@apache.org> on 2007/08/22 07:40:34 UTC
[jira] Updated: (STR-1967) Provide more version number granularity
in manifest.mf
[ https://issues.apache.org/struts/browse/STR-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Benedict updated STR-1967:
-------------------------------
Component/s: (was: Core)
Infrastructure
Assignee: (was: Struts Developers)
> Provide more version number granularity in manifest.mf
> ------------------------------------------------------
>
> Key: STR-1967
> URL: https://issues.apache.org/struts/browse/STR-1967
> Project: Struts 1
> Issue Type: Improvement
> Components: Infrastructure
> Affects Versions: 1.1.0
> Environment: Operating System: All
> Platform: All
> Reporter: Duncan Mills
> Priority: Minor
>
> As a vendor implementing Struts Support into our IDE (Oracle JDeveloper) it
> becomes important that we can detect exactly which version of Struts is
> available and do the right thing accordingly.
> The situation with 1.1 was an example of this. There are DTD changes between the
> final version and preview betas, but the manifest in both cases just has 1.1 as
> the Implementation-Version.
> I see from the nightly builds for 1.2 that the minor version is now being used
> but is set to 0, e.g. 1.2.0.
> Ideally a more granular numbering scheme should be adopted for 1.2, even down to
> the level of nightlies being identified using a _suffix to the minor build
> e.g. 1.2.<milestone>_<nightly> for a nightly build
> 1.2.<milestone> for a stable RC or Final
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.