Jukka Zitting wrote:
how about always suffixing release candidates that are voted on with
-rcN, and after acceptance releasing the same binaries again, this
time without suffixes? their md5 checksums would be identical, so
there should be no confusion as to which rc it is, and the release
would
Hi,
On 1/17/07, Christoph Kiehl [EMAIL PROTECTED] wrote:
Jukka Zitting wrote:
Good idea, but unfortunately we have the version number embedded
within the packages. It is included for example in the jar manifest
and in the Maven POM found in both in the source and binary packages.
Why not
Jukka Zitting wrote:
Why not just change the version in the pom.xml to 1.2.0-rc1 before
doing the rcX
release? If you use the maven release plugin this means no extra work
at all.
This way files like manifest etc should contain the right version
number. If
there are files that don't take the
Jukka Zitting wrote:
Ok, I see. Shouldn't it be possible to check out the revision you used
to create
the 1.2.0-rcN release and release it again as 1.2.0? I'm not quite
sure how the
release plugin handles this.
That would be optimal, i.e. vote on the last -rcN candidate and if the
vote
hi there,
how about always suffixing release candidates that are voted on with
-rcN, and after acceptance releasing the same binaries again, this
time without suffixes? their md5 checksums would be identical, so
there should be no confusion as to which rc it is, and the release
would have
Hi all,
Not too bring up an issue that's been discussed on the lists before but
I had a question about the ability to performed versioned operations
inside of a transaction. Apologies if the existing JIRA items cover this
but the Apache JIRA site seems to be down right now. It mainly concerns
[
https://issues.apache.org/jira/browse/JCR-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved JCR-390.
--
Resolution: Fixed
Fix Version/s: 1.3
Implemented as described. See sample repository.xml
hi olivier,
On 1/17/07, Olivier Dony [EMAIL PROTECTED] wrote:
Hi,
Apache's Jira seems to be down currently, but I wanted to provide
some feedback about issue JCR-645 (DatabasePersistenceManager
DatabaseFileSystem: try to gracefully recover from connection loss).
We tested this fix inside
[
https://issues.apache.org/jira/browse/JCR-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465457
]
Jaka Jaksic commented on JCR-619:
-
private static final long MAX_MEMORY = 16 * 1024 * 1024;
If I understand the
On Jan 17, 2007, at 5:47 AM, Carsten Ziegeler wrote:
Raphael Wegmueller wrote:
the usage of the 3rd version digit as a sort of rc counter sounds
rather confusing to me, too...
how about always suffixing release candidates that are voted on with
-rcN, and after acceptance releasing the same
On Jan 17, 2007, at 5:29 AM, Raphael Wegmueller wrote:
so what would happen if you had to release a real patch to
jackrabbit 1.2.1?
would it be versioned 1.2.1.1 then? or 1.2.2?
This is an open source project. Patches are source code diff files
and don't have versions. They just apply to
Roy T. Fielding wrote:
On Jan 17, 2007, at 5:47 AM, Carsten Ziegeler wrote:
Raphael Wegmueller wrote:
the usage of the 3rd version digit as a sort of rc counter sounds
rather confusing to me, too...
how about always suffixing release candidates that are voted on with
-rcN, and after
12 matches
Mail list logo
