Release trunk

[Deng Ching <oc...@apache.org>]

Hi All,

Any objections in doing a milestone release of trunk before we merge
MRM-980 branch?

These are the issues that have been fixed in trunk:

MRM-665 - DependencyTree fetchGraph causes high load with large databases
MRM-786 - Endless loop in "Dependency Tree" in cyclic dependencies?
MRM-404 - formatting in download box can sometimes be cramped
MRM-552 - Download link should be entitled "Plugin", not "Jar" for
maven plugins
MRM-585 - Project models for Maven 1 artifacts cannot be found in repo browse
MRM-816 - Resolution parameters in URL are not expanded
MRM-908 - pom.xml could not be parsed if it contains an UTF8-BOM
MRM-945 - Change the prompted message for users who do not have access
to the repository
MRM-1017 - quicksearch should not NPE without completeQueryString
MRM-1025 - remove the archiva database
MRM-1029 - Download box doesn't appear in the DependencyTree tab
MRM-1061 - 'Used By' page incorrect and 'Dependency Tree' page crash
when specifying dependency version using <dependencyManagement> in
parent POM.
MRM-1064 - Dependency Tree does not show dependencies correctly
MRM-1070 - Dependencies/Dependency Tree/Used by doesn't work correctly
with properties in version
MRM-1120 - groups that only have one subgroup, but also contain
artifacts, get collapsed in browse
MRM-1125 - default search should be AND not OR for multiple keywords
MRM-1242 - Incorrect Total File Count in Repository Statistics report
MRM-1255 - groupIds that are subsets of another groupId also display
artifacts from that group
MRM-1282 - introduce a metadata content repository API
MRM-1283 - migrate Archiva's "browse" functionality to use the
metadata content repository API
MRM-1286 - mailing lists tab doesn't work
MRM-1288 - migrate XMLRPC from DefaultRepositoryBrowsing to the
metadata content repository API
MRM-1292 - remove dependency-graph in favour of the
maven-dependency-tree library
MRM-1293 - migrate repository statistics to the metadata content repository
MRM-1299 - migrate RSS to the metadata content repository API
MRM-1300 - migrate search to the metadata repository
MRM-1301 - migrate reports to the metadata repository
MRM-1315 - delete artifact action logs to audit log using g:a:v format
instead of resource path as others do
MRM-1322 - Fix broken selenium tests
MRM-1323 - archiva webapp tests failed to run in internet explorer
MRM-1345 - update use of Nexus indexer
MRM-1362 - Add simple 'CRUD' pages for project-level metadata along
with a "generic metadata" plugin
MRM-1372 - Outdated instruction for Maven and JUnit still in
ReadMe.txt for selenium tests
MRM-1387 - Cannot build trunk of Archiva because of dependency missing
in Central
MRM-1394 - Replace the use of clickLinkWithText() with
getSelenium().open() for accessing navigation menu pages
MRM-1417 - Add basic managed repository management support on adding
repository, deleting repository, and loading repository by id
MRM-811 - Improve error message when pom does not match the artifact's
location in the repo
MRM-1285 - The content of the Downloads box is sometimes too large for the box


I can start the release this weekend unless others want to volunteer :)


Thanks,
Deng

Re: Release trunk

[Deng Ching <oc...@apache.org>]

I'm done merging MRM-980 branch to trunk, will just do some testing
first to make sure nothing was broken in trunk after the merge. Then
I'll release an alpha on Saturday.

-Deng

On Sat, Sep 25, 2010 at 12:13 PM, Deng Ching <oc...@apache.org> wrote:
> On Wed, Sep 15, 2010 at 2:27 PM, Brett Porter <br...@apache.org> wrote:
>>
>> On 15/09/2010, at 2:05 PM, Deng Ching wrote:
>>
>>> Hi All,
>>>
>>> Any objections in doing a milestone release of trunk before we merge
>>> MRM-980 branch?
>>
>> Depends on the intent...
>>
>> Clearly there are a lot of good improvements in trunk already, both in terms of performance / bugs and a couple of new features like the arbitrary metadata.
>>
>> However, if MRM-980 is done and just needs to be merged, I don't see any reason to wait unless we don't feel it's up to the same level of quality as the rest of trunk. Is that the case?
>
> Yes, I think we can already merge it. As for the UI for MRM-980, there
> is still a lot of room for improvement but this can be worked on in
> trunk after the merge.
>
>>
>> As for trunk, while the refactoring work is production ready, the file store is not. It's not far from being ready, and I know leaving trunk "unreleasable" was less than ideal. I don't mind it being in a release, but I'd only commit to make an upgrade path from 1.[1|2|3] -> 1.4, not through the interim releases. In other words, if we release it as is, they need to be prepared to rescan their repository regularly. I think such a release would be an alpha, not a milestone, despite our previous naming conventions.
>
> I agree, the release should be an alpha release instead of a milestone.
>
>>
>> So, the question is who the audience / intent is - do we want people to kick the tires on the refactoring, find bugs, and release an alpha now? Do we want people to try out the new features and release an alpha/milestone with that? Or do we really just want to push to what's needed for a release?
>
> The last one I would think.
>
>>
>> I think I'm fine with either an alpha release now (as long as another one follows quickly), or one with the branch merged in now. Either way, we should push forward to get 1.4 wrapped up in October.
>
> I vote for the latter -- merge first then do an alpha release after.
>
>
> Thanks,
> Deng
>

Re: Release trunk

[Deng Ching <oc...@apache.org>]

On Wed, Sep 15, 2010 at 2:27 PM, Brett Porter <br...@apache.org> wrote:
>
> On 15/09/2010, at 2:05 PM, Deng Ching wrote:
>
>> Hi All,
>>
>> Any objections in doing a milestone release of trunk before we merge
>> MRM-980 branch?
>
> Depends on the intent...
>
> Clearly there are a lot of good improvements in trunk already, both in terms of performance / bugs and a couple of new features like the arbitrary metadata.
>
> However, if MRM-980 is done and just needs to be merged, I don't see any reason to wait unless we don't feel it's up to the same level of quality as the rest of trunk. Is that the case?

Yes, I think we can already merge it. As for the UI for MRM-980, there
is still a lot of room for improvement but this can be worked on in
trunk after the merge.

>
> As for trunk, while the refactoring work is production ready, the file store is not. It's not far from being ready, and I know leaving trunk "unreleasable" was less than ideal. I don't mind it being in a release, but I'd only commit to make an upgrade path from 1.[1|2|3] -> 1.4, not through the interim releases. In other words, if we release it as is, they need to be prepared to rescan their repository regularly. I think such a release would be an alpha, not a milestone, despite our previous naming conventions.

I agree, the release should be an alpha release instead of a milestone.

>
> So, the question is who the audience / intent is - do we want people to kick the tires on the refactoring, find bugs, and release an alpha now? Do we want people to try out the new features and release an alpha/milestone with that? Or do we really just want to push to what's needed for a release?

The last one I would think.

>
> I think I'm fine with either an alpha release now (as long as another one follows quickly), or one with the branch merged in now. Either way, we should push forward to get 1.4 wrapped up in October.

I vote for the latter -- merge first then do an alpha release after.


Thanks,
Deng

Re: Release trunk

[Brett Porter <br...@apache.org>]

On 15/09/2010, at 2:05 PM, Deng Ching wrote:

> Hi All,
> 
> Any objections in doing a milestone release of trunk before we merge
> MRM-980 branch?

Depends on the intent...

Clearly there are a lot of good improvements in trunk already, both in terms of performance / bugs and a couple of new features like the arbitrary metadata.

However, if MRM-980 is done and just needs to be merged, I don't see any reason to wait unless we don't feel it's up to the same level of quality as the rest of trunk. Is that the case?

As for trunk, while the refactoring work is production ready, the file store is not. It's not far from being ready, and I know leaving trunk "unreleasable" was less than ideal. I don't mind it being in a release, but I'd only commit to make an upgrade path from 1.[1|2|3] -> 1.4, not through the interim releases. In other words, if we release it as is, they need to be prepared to rescan their repository regularly. I think such a release would be an alpha, not a milestone, despite our previous naming conventions.

So, the question is who the audience / intent is - do we want people to kick the tires on the refactoring, find bugs, and release an alpha now? Do we want people to try out the new features and release an alpha/milestone with that? Or do we really just want to push to what's needed for a release?

I think I'm fine with either an alpha release now (as long as another one follows quickly), or one with the branch merged in now. Either way, we should push forward to get 1.4 wrapped up in October.

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/