Sounds like a good plan. I've already updated the uP3 Jira project renaming it to uPortal3 Sandbox and making it read-only. I'll start on SVN next, creating a sandbox folder and moving up3 under it.
From the CVS sandbox what needs to be moved? The following modules exist: Merlin, al, gap, uP2_7_i18n, up3, userexperience, xalan Is uP2_7_i18n the DLM2/i18n code from SCT that we should move over? Do any of the other modules need to be moved? -Eric Andrew Petro wrote: > Starting with M5 sounds good to me. > > While I agree that uPortal cannot "take back" the existing M and RC > "uPortal 3" releases, I do think the verbiage on the downloads page > about those releases can be improved for better clarity about what > they are and how they relate to what will eventually be released as uP > 3 GA. > > I think some SVN adjustments are also in order -- the code currently > in /up3/ needs to be moved to a less confusing namespace, probably in > /sandbox/, which nicely relates to the work of moving over the CVS > sandbox to un-orphan Mark's improved DLM code. > > Andrew > > >> I completely agree, the question of what we call the next 3 related >> release? >> >> As much as starting over with M1 would be nice we already have >> released artifacts with M1-M4 and RC1 names. I'd bet that would cause >> a fair amount of confusion. So is starting at M5 and only doing >> milestone releases until we have a real RC the way to go? I'm >> thinking yes but I'd like some confirmation. >> >> -Eric >> >> Andrew Petro wrote: >> >>> Eric, >>> >>> I strongly feel that we should take care in the naming of releases >>> to reflect what they are. The amount of new functionality snuck in >>> post-RC on 2.6.0 was probably too much and probably slowed things >>> up, someone should slap my wrist. >>> >>> While the uPortal sandbox project produced a release named a >>> "release candidate" I think on sober second thought that was a >>> mistake -- that it wasn't actually a candidate for release since it >>> was acknowledged at the time to lack significant amounts of needed >>> functionality. >>> >>> Going forward IMHO we should absolutely switch back to producing >>> milestones until there's something that's a candidate for release. >>> RC needs to mean something that is functionally complete and >>> releasable but for a need for QA. >>> >>> Andrew >>> >>> >>> >>>> I'm also looking for ideas on naming versions in Jira. We have >>>> already had M1 through M4 and an RC from the sandbox code. Should >>>> we start with a 3.0.0-M5 and then go to a RC2 once we're at the RC >>>> stage? >>>> >>>> -Eric >>>> >>> > >
smime.p7s
Description: S/MIME Cryptographic Signature
