Details

    • Type: Task Task
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      There is a thread on the dev mailing list: dev process for 2.0.1/2.1

      and I would like to document the outcome of this discussion so we can subsequently reference it.

        Issue Links

          Activity

          Hide
          Jason van Zyl added a comment -

          So far it looks like we're going for:

          • the Flying Fish technique where we'll have 2.1 on the trunk and a 2.0.x on a branch
          • the use of 2.1-SNAPSHOT instead of 2.1-alpha-1-SNAPSHOT, so maybe we could use
            the release metadata to help with moving to the next version in the release plugin. It should
            be easy to see where we are moving to.
          • separate modules will be made for projects with separate lifecycles
          • we will have separate JIRA projects for each plugin
          Show
          Jason van Zyl added a comment - So far it looks like we're going for: the Flying Fish technique where we'll have 2.1 on the trunk and a 2.0.x on a branch the use of 2.1-SNAPSHOT instead of 2.1-alpha-1-SNAPSHOT, so maybe we could use the release metadata to help with moving to the next version in the release plugin. It should be easy to see where we are moving to. separate modules will be made for projects with separate lifecycles we will have separate JIRA projects for each plugin
          Hide
          Jason van Zyl added a comment -

          We can also incorporate the use of archetypes here to make the process easier for community memebers to get involved:

          I think there are two things that we can do here with the way archetypes currently work.

          1) To provide a partial archetype for components where simple tests cases are added to a project. So someone could, for example, easily create a test case that would get laid down in maven-core to test some specific issue. We might end up with many test cases but I think this is ok and we could then more easily map issues to tests cases that resolved those issues. Here I think all we would have to add now is a parameter for the name of the test class.

          2) Provide an archetype for an integration test

          Currently I'm working with Jorg to make the archetype system better in terms of prompting for information (parameter metadata), and we could easily document what archetypes are to be used for particular cases. We could probably just document the CLI usage to create the appropriate archeypte for now. IDE support would be better but some documentation would work for now.

          Show
          Jason van Zyl added a comment - We can also incorporate the use of archetypes here to make the process easier for community memebers to get involved: I think there are two things that we can do here with the way archetypes currently work. 1) To provide a partial archetype for components where simple tests cases are added to a project. So someone could, for example, easily create a test case that would get laid down in maven-core to test some specific issue. We might end up with many test cases but I think this is ok and we could then more easily map issues to tests cases that resolved those issues. Here I think all we would have to add now is a parameter for the name of the test class. 2) Provide an archetype for an integration test Currently I'm working with Jorg to make the archetype system better in terms of prompting for information (parameter metadata), and we could easily document what archetypes are to be used for particular cases. We could probably just document the CLI usage to create the appropriate archeypte for now. IDE support would be better but some documentation would work for now.
          Hide
          Brett Porter added a comment -

          I've put this to a vote on the list so we can move forward with it

          Show
          Brett Porter added a comment - I've put this to a vote on the list so we can move forward with it
          Hide
          Jason van Zyl added a comment -

          Now documented here:

          http://docs.codehaus.org/display/MAVEN/Development+Process

          May undergo a few changes but that's pretty much the end result.

          Show
          Jason van Zyl added a comment - Now documented here: http://docs.codehaus.org/display/MAVEN/Development+Process May undergo a few changes but that's pretty much the end result.
          Hide
          Jason van Zyl added a comment -

          Still needs to be reviewed and I shouldn't have closed this issue until there was agreement on the document as being final

          Show
          Jason van Zyl added a comment - Still needs to be reviewed and I shouldn't have closed this issue until there was agreement on the document as being final

            People

            • Assignee:
              Brett Porter
              Reporter:
              Jason van Zyl
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: