U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » Community » U++ community news and announcements » Easier svn releases filtering

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Easier svn releases filtering [message #25475]

Thu, 25 February 2010 10:42

koldo
Messages: 3357
Registered: August 2008

Senior Veteran

Hello all

In an Upp meeting it was proposed to label svn releases to let to classify them.

To define it better I include you a proposal and the advantages.

I think it is important so, although almost everything could be changed in this proposal, please try to be as constructive as possible.

Proposal

- The format of svn release comments could be:

[PACKAGE], [RELEASE TYPE]: Comments

where:
- [PACKAGE] would be the package name
- [RELEASE TYPE] would be the type and importance of release. Valid values could be:
--- "major": A relevant improvement
--- "fix": A bug fix
--- No release type if it is not major change or a fix

for example:

   - Core, major: Added support to xxx
   - GridCtrl, fix: Fixed problem xxx
   - Uppweb: Fixed some spelling errors

Advantages

- Easier to filter Svn releases over RSS feeds
Svn releases not labeled would not appear in RSS
--- See dolik.rce (Honza) initiative in http://www.ultimatepp.org/forum/index.php?t=msg&th=4956& amp;start=0&
--- This could solve cbbporter comments in last Upp meeting

- Easier to do announcements as only releases labeled as major or fixes would be included in announcement text

Best regards
Iñaki

Report message to a moderator

Re: Easier svn releases filtering [message #25476 is a reply to message #25475]

Thu, 25 February 2010 10:50

Sc0rch
Messages: 99
Registered: February 2008
Location: Russia, Rubtsovsk

Member

Hello, koldo!

What about next?

- Core: fixed bugs...
+ CtrlLib: new features...
* CtrlCore: changes...

and keep changes sorted. For example, this order:
1) fixed bugs,
2) new features,
3) changes
or replace 2 and 3.

Another way:

Bugfixes:
  Core: ...
  CtrlLib: ...

Changes:
  ...

New features:
  ...

I like the second way. But I don't know, which of them better for svn.

Best regards,
Anton

[Updated on: Thu, 25 February 2010 10:51]

Report message to a moderator

Re: Easier svn releases filtering [message #25479 is a reply to message #25476]

Thu, 25 February 2010 12:21

koldo
Messages: 3357
Registered: August 2008

Senior Veteran

Sc0rch wrote on Thu, 25 February 2010 10:50

Hello, koldo!

What about next?

- Core: fixed bugs...
+ CtrlLib: new features...
* CtrlCore: changes...

and keep changes sorted. For example, this order:
1) fixed bugs,
2) new features,
3) changes
or replace 2 and 3.

Another way:

Bugfixes:
  Core: ...
  CtrlLib: ...

Changes:
  ...

New features:
  ...

I like the second way. But I don't know, which of them better for svn.

Best regards,
Anton

Hello Anton

It is no exactly the same. I refer to svn revision commit log messages, like in http://code.google.com/p/upp-mirror/source/list.

It would require to follow a strict text format in those messages.

Best regards
Iñaki

[Updated on: Thu, 25 February 2010 13:33]

Report message to a moderator

Re: Easier svn releases filtering [message #25481 is a reply to message #25479]

Thu, 25 February 2010 12:52

Sc0rch
Messages: 99
Registered: February 2008
Location: Russia, Rubtsovsk

Member

koldo wrote on Thu, 25 February 2010 17:21

I've understand you. Common style in coding/commenting is always good idea!

[Updated on: Thu, 25 February 2010 12:52]

Report message to a moderator

Re: Easier svn releases filtering [message #25482 is a reply to message #25475]

Thu, 25 February 2010 13:59

dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic

Ultimate Contributor

If we define clean rules, we can even enforce them using pre-commit hook. Same mechanism as is used now for rejecting commits without log (see this thread), only few more lines Wink

And by the way: Mirek proposed something similar here.

Regards,
Honza

Report message to a moderator

Re: Easier svn releases filtering [message #25485 is a reply to message #25482]

Thu, 25 February 2010 14:39

koldo
Messages: 3357
Registered: August 2008

Senior Veteran

dolik.rce wrote on Thu, 25 February 2010 13:59

If we define clean rules, we can even enforce them using pre-commit hook. Same mechanism as is used now for rejecting commits without log (see this thread), only few more lines Wink

And by the way: Mirek proposed something similar here.

Regards,
Honza

Hello Honza

Yes it is true. It was not in a meeting Rolling Eyes

Quote:

I am now only thinking whether we should introduce some convention about "minor changes". Like putting '.' before commit message?

".fixed small type"

vs

"Refactored theide search"

Mirek

Good idea too. And good way to enforce it Honza. Smile

.

With all of this implemented we can know:

- Package affected

- It is main Upp or it is Bazaar

- Change importance. For me Mirek's idea is enough.

Best regards
Iñaki

Report message to a moderator

Re: Easier svn releases filtering [message #25498 is a reply to message #25482]

Fri, 26 February 2010 12:08

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

dolik.rce wrote on Thu, 25 February 2010 07:59

If we define clean rules, we can even enforce them using pre-commit hook. Same mechanism as is used now for rejecting commits without log (see this thread), only few more lines Wink

And by the way: Mirek proposed something similar here.

Regards,
Honza

Not only that, I am following my rules Smile

I think this really a very good idea.

I am also using "Syncing uppdev" for commits that only backup that devils nest... Not sure how to properly specify it, it is backuping of testcases, testing code, developed code and other non-important things.

Report message to a moderator

Re: Easier svn releases filtering [message #25499 is a reply to message #25498]

Fri, 26 February 2010 12:13

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

I believe we should just keep it simple. I would like to see "changes", "fixes", "unimportant".

Maybe, leave changes without anything, mark fixes with "*" and "unimportant" (like syncing uppdev) with ".":

Core: Xmlize now supports Values
*Core: Xmlize Color Value bug fixed
.Core: fixed formatting
.uppdev

Also, name of package without anything if it is uppsrc, but

reference/ArrayCtrlCtrls2: new ArrayCtrl example demostrating....

and also name of nest alone if it affects more than single package in the nest. And if commit affects several packages, separate them with colon.

Mirek

Report message to a moderator

Re: Easier svn releases filtering [message #25502 is a reply to message #25499]

Fri, 26 February 2010 12:37

koldo
Messages: 3357
Registered: August 2008

Senior Veteran

Hello Mirek

Quote:

I believe we should just keep it simple

Yes

Quote:

Maybe, leave changes without anything, mark fixes with "*" and "unimportant" (like syncing uppdev) with ".":

If you see commit messages in SVN now some texts are not right. Because of it I would put a mark to all messages. If a message text has not a mark, dolik.rce technology would refuse it.

All other rules are good for me. If dolik.rce could enforce them at much as possible it would be perfect.

Best regards
Iñaki

Report message to a moderator

Re: Easier svn releases filtering [message #25506 is a reply to message #25502]

Fri, 26 February 2010 15:01

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

koldo wrote on Fri, 26 February 2010 06:37

If you see commit messages in SVN now some texts are not right. Because of it I would put a mark to all messages. If a message text has not a mark, dolik.rce technology would refuse it.

Ahm, I am not 100% sure we should enforce that by svn. There still can be commits that cannot categorized this way.

Mirek

Report message to a moderator

Re: Easier svn releases filtering [message #25514 is a reply to message #25506]

Fri, 26 February 2010 16:16

dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic

Ultimate Contributor

Hi,

luzr wrote on Fri, 26 February 2010 15:01

koldo wrote on Fri, 26 February 2010 06:37

If you see commit messages in SVN now some texts are not right. Because of it I would put a mark to all messages. If a message text has not a mark, dolik.rce technology would refuse it.

Ahm, I am not 100% sure we should enforce that by svn. There still can be commits that cannot categorized this way.

Mirek

This could be solved by some rule like "if log starts with _, accept without further checks"... On the other hands, too complicated rules are not good idea as well.

Generally, I think any of this should by enforced only on release directories (bazaar,examples,reference,tutorial,uppsrc).

Honza

Report message to a moderator

Re: Easier svn releases filtering [message #25517 is a reply to message #25499]

Fri, 26 February 2010 18:33

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

luzr wrote on Fri, 26 February 2010 06:13

Core: Xmlize now supports Values
*Core: Xmlize Color Value bug fixed
.Core: fixed formatting
.uppdev

Well, whatever, I have started using above now Smile

Mirek

Report message to a moderator

Re: Easier svn releases filtering [message #25598 is a reply to message #25517]

Wed, 03 March 2010 06:19

sergeynikitin
Messages: 748
Registered: January 2008
Location: Moscow, Russia

Contributor

Friends! Common practice is

- Core: fixed bugs...
+ CtrlLib: new features...
* CtrlCore: changes...

In addition to visually obvious that the '-' is something negative '+' - a new possibility '*' - willcard - all the rest.
It is possible to extend this practice to '.' - Unimportant (I propose mnemonic rule - point - litle asterisk - little willcard).

PS
May be the right to vote? (although personally I'll take the general view)

SergeyNikitin<U++>( linux, wine )
{
under( Ubuntu || Debian || Raspbian );
}

Report message to a moderator

Previous Topic:	U++ Meeting February 23 21:00UTC
Next Topic:	U++ 2232 released

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Apr 27 20:01:15 CEST 2024

Total time taken to generate the page: 0.91860 seconds