>>> Work in a branch. It it works, fine. Maybe we can also tag the current >>> version, and move to a new version from this tag. > > +1 to make the migration on a branch. I expect troubles which should not > interfere with other work. Let's stabilize the MINA2.0 branch and then > merge back. Should be not too much conflicting code. > >> Hmm.. I think we shall release Vysper with latest MINA version? So >> tagging should be fine. > > I don't get what this tag is all about? > >> Bernd: Want to take a call on this? >> >> I think I can't tag now, as I have coded on trunk :-( So if someone >> else can move the code to tag will be great. > > I don't understand that. If you have local changes you still could > create a branch using URLs, couldn't you?
Got it. Not a master on SVN :-( >> community, since Nov 2007. We had a total of 861 messages on our ML's. > > That's good. But remember that people might get annoyed by increased > off-topic ML traffic and might drop out (those interested only in MINA > and not in Vysper). Make sure to monitor subscription figures, too and > eventually fork lists. Can't monitor the Subscribers figures (don't have privileges). We need to wait for MINA Board report for these details. Either ways, having an active community is very important for an Open Source project. It forms one of the evaluation criteria for User's. Its an assurance that if there are any problem, they will be addressed. >From my POV, it's an input to COTS Usage Risk Analysis, that is being done before actually using the library. -- thanks ashish
