[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-mtj-dev] MTJ SR1 work

I think the tag is in place I see a 1.0GA tag on SVN. So we need a 1.0.1 branch. I guess we can branch the plugins as needed if the plugin receives a new development (or a breaking fix). If everybody agrees
--
Gorkem

On Thu, Jun 25, 2009 at 4:17 PM, Craig Setera <craigjunk@xxxxxxxxxx> wrote:
I would agree.  I would:

* Expect that we would tag 3.5 and create a branch for 3.5.1. 
* The tag doesn't move. 
* Pure bug fixes go on the 3.5.1 branch. 
* New development goes on trunk. 
* If we decide to ship something in 3.5.1 that isn't a pure bug fix, we agree amongst the
team (via this email list) and then merge it to the 3.5.1 branch from trunk.

This is the way I've tended to do this type of work in the past and believe it is the correct approach.  The question is whether we have tagged and branched yet?  This is something any committer could do, although I won't have time until this weekend (at least).

Craig


On 6/25/09 8:01 AM, Gorkem Ercan wrote:
Now that Galileo is out. Is the HEAD open for new development now?

Craig, I think your suggestion is to use the HEAD for both bug fixes and new features. Am I correct? IMHO It is better to branch for service release because it would allow us to be more liberal with the new features. I guess we can always backport some of them to SR branch
--
Gorkem



On Thu, Jun 18, 2009 at 10:33 PM, Jon Dearden <jdearden@xxxxxxx> wrote:

Craig, is there a general mechanism available in the API for validating user data entered into vendor-specific JAD properties?

 

 

Cheers,

Jon

 


From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Friday, June 12, 2009 9:31 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] MTJ SR1 work

 

What are we thinking in terms of additional features/functions for this point release?  I know that that isn't all that standard for most Eclipse projects, but given that we are still trying to get all of the basics in place it seems we might want to consider it.  I'm thinking, in particular, that I might like to try to find the time to go back and finish out the SDK provider extension point work I started.

If we are starting point release work, do we have appropriate source control branches in place?

Craig

On 6/11/09 1:07 PM, Eric Hildum wrote:

Everyone, we have had a very successful development and release of MTJ
1.0. Thank you all for your hard work and contributions.
 
Even though Galileo has not been officially released yet, I think it
is time we start looking at the work for SR1. Looking at the current
bug list for MTJ, I see 42 open bugs at this time. Some of these we
definitely need to resolve for SR1, others it is not clear to me that
they are still valid or at the right severity/priority. Could we all
take a look at the open bugs and:
 
1. See if they are still valid. If not, would the reporters please close them
2. Check to see if they have the correct severity/priority.
3. Make sure that we have correctly identified and recorded in
Bugzilla the correct blocking/depends on relationships
4. Update the reports with any additional information that may have come in.
 
Also, I noticed that at least one bug has a valid patch but seems to
be moving into new problems. Could we close the initial problem report
as that has been fixed, and open a separate bug report so we can keep
the bugs on a single topic?
 
  
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev



_______________________________________________ dsdp-mtj-dev mailing list dsdp-mtj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev